RUN_DEPENDS and portmaster

[Stefan Esser]

Am 18.09.18 um 14:05 schrieb Matthias Fechner:
> Dear Stefan,
> 
> Am 17.09.2018 um 14:31 schrieb Stefan Esser:
>> But the behavior of portmaster will not be changed.
>> RUN_DEPENDS are dependencies required to run a port, not dependencies
>> required to install a port.
>>
>>
>> And I do not care whether bsd.port.mk treats RUN_DEPENDS as if they
>> were INSTALL_DEPENDS (which do not exist). The fact that bsd.port.mk
>> works in that way is due to the fact, that it generally executes sub
>> processes in a depth first manner. Portmaster distinguishes build and
>> run dependencies and makes sure, that build dependencies not only exist,
>> but are updated before the ports they depend on, while bsd.port.mk will
>> use any build dependency that satisfies the range requirements (if any)
>> and does not upgrade existing but outdated (in the sense that an upgrade
>> is available) dependencies. Portmaster will then upgrade any out-dated
>> run dependencies (again if an upgrade is available, not only if it is
>> strictly required). Thus portmaster guarantees, that a port is built
>> with the latest available build tools, and that run dependency upgrades
>> see the upgraded port that requires them, in case they depend on it.
> 
> I fully understand you.
> 
> Maybe it will be a good idea to phase portmaster out as it seems to be a
> unmaintable beast?
> 
> Maybe synth can replace it for users that are not used to poudriere?

I have been using a portmaster-rewrite for many months, which is ready
for release except for some performance tuning. (The portmaster in ports
is not un-maintainable, but it's hard to modify a monolithic 4000 line
shell script that uses global variables to pass state and recursive
invocation of itself to provide local state when required.)

The performance problems are caused by bad design of the FLAVOR feature,
which ignored the requirements of tools like portmaster (I've written
about this at length when FLAVOR support had been committed).

Synth is a non-starter for me, since it is written in Ada and only
available on i386/amd64. I have plans to implement the functionality
of synth in portmaster (not really hard, since the complex parts are
the logic that deals with moved ports and conflicts, while the actual
port building is simple). Portmaster can already create packages
without installing them (unless they are BUILD_DEPENDS of some later
port, of course) and you can populate your local repository with
portmaster.

Different from poudriere or synth, portmaster adapts to the preferences
of the user (and e.g. upgrades samba48 used by some port that specifies
a dependency on samba46, if the system already has an outdated samba48
installed).

Portmaster will use what's available on a system and does allow selective
upgrades (keeping some ports at a back-level on purpose, but still upgrade
other ports that depend on them), while a poudirere/pkg based upgrade will
typically require all dependencies to exactly match what was present at
the time the package was built (in a clean environment, not resembling the
system the packages are going to be installed on).

Both, portmaster and poudriere/pkg have their use-cases, and there is only
a partial overlap. There are quite a number of portmaster users, and they
use it since their use-cases are not well covered by other tools.

The way the ports system handles installs (in that it installs RUN_DEPENDS
before the port that needs them) is an artifact of the way Makefiles
naturally work, i.e. of the tool the ports system is based on.

I do not understand why you intend on having RUN_DEPENDS cause installation
of dependencies before your port. If you need those dependencies before the
port is installed, then they are not really run dependencies, but dependencies
of your particular build process.

Portmaster has worked for far more than a decade with >20,000 ports. I do
not see that your single port that expects run dependencies to be available
before the installation has completed is reasonable cause to change the way
portmaster works with dependencies. It pre-dates the "new" ports framework
by far, and it used to be common practice, that changes respect established
practices.

BTW: Your port-install target will not be run when installing from a package
(or building a package) anyway. Portmaster will take care of providing the
required dependencies, as will pkg.

So what's the reasoning that this test in do-install is required at all?

You already specify exact versions in the RUN_DEPENDS, which are checked
by the ports framework. Portmaster will take care, that all these ports
are re-built to the latest level (hopefully satisfying the version test)
after gitlab-ce has been installed. If you use pkg, the test is performed
at install time, too.

Are there any PRs due to lack of that test?

Regards, STefan