Reclaim removes build dependencies

[haberg-1 (Hans Åberg)]

Using 'port reclaim' produces the list below; when answering Yes, thus uninstalling them, and then running 'port upgrade outdated', they get reinstalled again. So somehow, there are some hidden dependencies that 'port reclaim' does not see. Possibly they are related to the port lilypond-devel.

port reclaim
--->  Checking for unnecessary unrequested ports
Unrequested ports without requested dependents found:
 perl5.30  @5.30.3_0
 cmake  @3.17.3_0
 mesa  @17.1.6_2+osmesa+python27
 xorg-libXtst  @1.2.3_1
 xorg-libXi  @1.7.10_0
 xorg-libXxf86vm  @1.1.4_1
 xorg-libXrandr  @1.5.2_0
 xorg-libXinerama  @1.1.4_1
 xorg-libXcomposite  @0.4.5_0
 xorg-libXp  @1.0.3_2
 xorg-libXcursor  @1.2.0_0
 xorg-libXdamage  @1.1.5_0
 xorg-libXfixes  @5.0.3_1
 libarchive  @3.4.3_0
 flex  @2.6.4_0
 gmake  @4.3_0
 pkgconfig  @0.29.2_0
 potrace  @1.16_0
 libzzip  @0.13.69_0
 dbus  @1.12.16_0
 woff2  @1.0.2_0
 libspiro  @20190731_0
 libuninameslist  @20180701_0
 lzo2  @2.10_0
 libuv  @1.38.0_0
 libepoxy  @1.5.4_1+python38
 hicolor-icon-theme  @0.17_0
 t1utils  @1.41_0
 texlive-common  @2019_0
Would you like to uninstall them? [Y/n]:

[ryandesign (Ryan Carsten Schmidt)]

Presumably reclaim is designed to remove build dependencies since they are not needed after the port has been built. From the list you showed, cmake, flex, gmake, and pkgconfig definitely fall into that category. But if you then upgrade ports and need to build them from source, build dependencies will again be needed and will be reinstalled. This is as designed, though evidently not as you expected. It might be nice if MacPorts offered the option to keep build dependencies. And that option should probably be on by default if MacPorts is configured to buildfromsource always.

[ryandesign (Ryan Carsten Schmidt)]

Looking specifically at lilypond-devel, it has rather a lot of build dependencies:

$ port deps lilypond-devel
Full Name: lilypond-devel @2.21.2_0
Build Dependencies:   autoconf, bison, flex, fontforge, gmake, p5.28-encode,
                      p5.28-pod-escapes, p5.28-pod-simple, p5.28-podlators,
                      p5.28-scalar-list-utils, pkgconfig, t1utils, texinfo,
                      texlive-fonts-recommended, texlive-metapost,
                      urw-core35-fonts
Library Dependencies: pango, extractpdfmark, ghostscript, guile18, python38

(and those build dependencies have dependencies, and so on).

[ryandesign (Ryan Carsten Schmidt)]

It would also be nice if reclaim could be intelligent about keeping build dependencies for ports that are known not to be distributable, but unfortunately MacPorts base does not know whether any port is distributable. This capability exists outside of MacPorts, and should be integrated into MacPorts base so that enhancements like this would be possible.

[haberg-1 (Hans Åberg)]

For example, the xorg addition may be due to a setting of fontforge which is not needed by lilypond-devel, and then that dependency is not propagated to reclaim.

[jjstickel (Jonathan Stickel)]

FWIW, port_cutleaves has this feature, i.e, to keep build dependencies:

$ port_cutleaves -h
port_cutleaves [-b] [-F value] [-l] [-t value] [-V] [-help] [-?]

Options:
 -b                   Don't count ports as leaves when they are only needed at build time

Perhaps this could be ported to port reclaim.

[CodingMarkus]

Replying to ryandesign:

Presumably reclaim is designed to remove build dependencies since they are not needed after the port has been built. From the list you showed, cmake, flex, gmake, and pkgconfig definitely fall into that category. But if you then upgrade ports and need to build them from source, build dependencies will again be needed and will be reinstalled. This is as designed

In that case the whole thing is "broken by design" because that's not a meaningful behavior whatsoever. Nobody has any advantage, if packets gets constantly removed just to have all of them re-installed whenever he runs port upgrade outdated. This only makes upgrading more of a pain and will take way longer, just to save a few couple of megabytes in between upgrades.

If something has a broken design, that's a defect as well. Software developers cannot use "but it works like designed" as an excuse if the design itself is broken. Otherwise I could make an app that always destroys your entire system if you click a specific button and when people complain I say "no, that's fine, that's how I designed that button". But it's not fine, since such a button shouldn't even exist, nobody wants such a button, nobody has any use for such a button, the defect in that case is the sole existence of the button or what it does, regardless if it works as intended by the developer.

Packets should always list build and run dependencies and both should prevent reclaim from removing the packet. Also port should remember for all installed packets if that packet was built from source or not. If not, and only if not, it can ignore its built dependencies. These two are the only required changes. If build dependencies change with upgrades or if a packet switches from building to pre-built or the other way round, this will all would sort out correctly without any additional changes to that. Just have port remember if a packet was built and have reclaim treat build dependencies as run dependencies in case it was. I'm pretty sure nobody will ever oppose that behavior and if that really happens, you can still add a flag to reclaim to ignore build dependencies if that's really what the user wants.

[haberg-1 (Hans Åberg)]

Build dependencies are only needed if the binaries are not available. So one might want to keep them before the binaries have arrived, and remove them when they have. Examples that are expensive, taking a long time to rebuild, are older versions of GCC and Clang, that a program may ask for specifically. This will happen particularly when the new Mac OS has been released.

Finding a good method might be complicated. Inputs:

MacPorts might check if there is a binary available of a build dependency, and 'reclaim' only removes it when it is. Otherwise, 'reclaim' might ask if it should be removed, that is when, when removal would cause a dependency rebuild.

Alternatively, MacPorts might cache the local build dependency binary, and use that before the official binaries have arrived. Then there need to be no change to 'reclaim'.