RUN_DEPENDS and portmaster

Stefan Esser se at freebsd.org
Mon Sep 17 12:31:56 UTC 2018


Am 17.09.18 um 07:47 schrieb Matthias Fechner:
> Am 10.09.18 um 12:16 schrieb Mathieu Arnold:
>> Reading Mk/bsd.port.mk at line 5274, run-depends are installed before
>> do-install runs.
> 
> thanks, I see it the same way and created a PR for it, to get this fixed
> in portmaster.

You are of course free to create a PR against portmaster.

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 have spent hundreds of hours to work around the bad design of the
FLAVOR support, which ignored the requirements of tools like portmaster
or portupgrade. Changes to the port infrastructure tend to ignore the
existence and requirements of build tools that have a decade long
history and use cases not covered by the port infrastructure alone.

I'm not going to spend any time on a change that made portmaster install
RUN_DEPENDS before executing "make install" for a port.

You are free to create a patch to that effect, but be aware that it is
extremely likely to break lots of upgrade scenarios, and I'll make you
responsible for fixing them (or back-out your assumed patch that treats
run dependencies as if they were build dependencies).

Regards, STefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20180917/0490d968/attachment.sig>


More information about the freebsd-ports mailing list