RFE: port upgrade should consider variants when computing dependencies

[ryandesign (Ryan Carsten Schmidt)]

apr-util usually depends on db4, but if you install apr-util with the +no_bdb variant, this deletes the db4 dependency. This is how I installed my apr-util 1.2.2, and this is how I want it. I do not want db4 on my system.

Attempting to upgrade apr-util to 1.2.6 wants to install db4, however. It seems that port upgrade doesn't use the variants that were specified in the last install when computing the needed dependencies.

I brought this up on the mailing list:

​http://opendarwin.org/pipermail/darwinports/2006-April/033312.html

Daniel J. Luke suggested I provide the output of port -d -v upgrade apr-util so here it is:

$ sudo port -d -v upgrade apr-util
Password:
DEBUG: Found port in file:///opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports/devel/apr-util
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: apr-util 1.2.6_0 exists in the ports tree
DEBUG: apr-util 1.2.2_1 is installed
DEBUG: Found port in file:///opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports/devel/apr
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: apr 1.2.6_0 exists in the ports tree
DEBUG: apr 1.2.6_0 is installed
DEBUG: No need to upgrade! apr 1.2.6_0 >= apr 1.2.6_0
DEBUG: Found port in file:///opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports/textproc/expat
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: expat 2.0.0_1 exists in the ports tree
DEBUG: expat 2.0.0_1 is installed
DEBUG: No need to upgrade! expat 2.0.0_1 >= expat 2.0.0_1
DEBUG: Found port in file:///opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports/textproc/libiconv
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: libiconv 1.10_1 exists in the ports tree
DEBUG: libiconv 1.10_1 is installed
DEBUG: No need to upgrade! libiconv 1.10_1 >= libiconv 1.10_1
DEBUG: Found port in file:///opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports/databases/db4
DEBUG: db4 is *not* installed by DarwinPorts
DEBUG: Changing to port directory: /opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports/databases/db4
DEBUG: Searching for dependency: db4
DEBUG: Didn't find receipt, going to depspec regex for: db4
DEBUG: Requested variant powerpc is not provided by port db4.
DEBUG: Requested variant darwin is not provided by port db4.
DEBUG: Requested variant macosx is not provided by port db4.
DEBUG: Executing variant darwin_8 provides darwin_8
DEBUG: Skipping completed com.apple.main (db4)
DEBUG: Skipping completed com.apple.unarchive (db4)
--->  Fetching db4
DEBUG: Executing com.apple.fetch (db4)
--->  db-4.3.29.tar.gz doesn't seem to exist in /opt/local/var/db/dports/distfiles/db4/4.3.29
--->  Attempting to fetch db-4.3.29.tar.gz from http://downloads.sleepycat.com/
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  1 5803k    1   98k    0     0  31625      0  0:03:07  0:00:03  0:03:04 61949^C

He also suggested I upgrade with -n (skipping the dependencies) which was a successful workaround.

[gwhitneycom1@…]

Proposed patch against r25313 to resolve this issue

[gwhitney@…]

As promised toward the end of my recent note ​http://lists.macosforge.org/pipermail/macports-dev/2007-May/001673.html to macports-dev, here is a patch which adds this functionality. In addition, there are three places (rather than the usual two) where variant specifications can come from in an upgrade: the command line, the installed version of the port, and variants.conf. This patch also rationalizes the precedence of those sources to be in the order listed, with command line taking highest precedence as always.

Hope this helps.

[nox@…]

This is not anymore relevant, is it?

[jmroot (Joshua Root)]

Replying to nox@macports.org:

This is not anymore relevant, is it?

The patch doesn't seem to have ever been applied. Was this fixed in some other way?

[jmroot (Joshua Root)]

updated man page section of the patch

[jmroot (Joshua Root)]

updated patch against current base

[ralph@…]

This bug is still relevant. See for example #15662.

[bcbarnes@…]

I believe this hit me in bug #16831 (upgrading octave installing g95 in a non-g95 variant).

[vinc17@…]

Cc Me!

[dbevans (David B. Evans)]

This still does not seem to be addressed. My example (using svn trunk) is pango +no_x11 which installs properly as per the variant description (no X11 dependencies) but a subsequent

sudo port upgrade pango

needlessly installs Xft2 and all its X11 dependencies (which are currently growing by leaps and bounds) during the upgrade. Xft2 is a default dependency that is removed by the +no_x11 variant in the Portfile.

upgrade should follow dependencies based on the selected variants of the installed port being upgraded not its default ones. This is a major problem for people who want to set up a maintainable native GTK+ (i.e. X11 free) development environment (among others).

[aetherknight@…]

Cc Me!

[aetherknight@…]

Cc Me!

[aetherknight@…]

Cc Me!

[korpios@…]

Cc Me!

[korpios@…]

This is by far the most obnoxious wart currently in MacPorts. I've been increasingly avoiding the use of MacPorts to install tools and libraries because I know it's going to wipe out my variants the moment I run "port upgrade". :/

[gwhitney]

Revived old patch yet again, tested, and checked in as r44362. All of the above test cases work for me. However, this is by far the most complex change to macports that I have attempted, so please test and watch for any suspicious behavior. Let me know if you find any problems.

[dbevans (David B. Evans)]

It still does not honor variants set in variants.conf. In my case, building gimp2 in a MacPorts installation where +no_x11 +quartz is set in variants.conf.

port upgrade gimp2

follows the default variants in dependencies causing

X11 libraries to be installed but

port deactivate gimp2
port install gimp2

works correctly. So I think you need to add support for variants in variants.conf.

Note that this also happens for port deps

port deps gtk2 (with variants +no_x11 +quartz in variants.conf)

gtk2 has build dependencies on:
        pkgconfig
        gtk-doc
gtk2 has library dependencies on:
        cairo
        fontconfig
        freetype
        glib2
        jpeg
        tiff
        libiconv
        libpng
        jasper
        atk
        pango
        gettext
        zlib
        xorg-libXi
        xorg-libXrandr
        xorg-libXcursor
        xorg-libXinerama
        xorg-libXdamage
        xorg-libXcomposite
        xorg-libXfixes
gtk2 has runtime dependencies on:
        shared-mime-info

which always shows dependencies based on the default variants without regard to variants.conf but

port deps gtk2 +no_x11

gtk2 has build dependencies on:
        pkgconfig
        gtk-doc
gtk2 has library dependencies on:
        cairo
        fontconfig
        freetype
        glib2
        jpeg
        tiff
        libiconv
        libpng
        jasper
        atk
        pango
        gettext
        zlib
gtk2 has runtime dependencies on:
        shared-mime-info

Perhaps there is shared code?

[dbevans (David B. Evans)]

Cc Me!

[dbevans (David B. Evans)]

Reopened due to the variants.conf issue mentioned above. Given the severity of this problem as mentioned by several folks above, I would vote to move this to a 1.7.1 milestone rather than 1.8.0 if that would get a fix out to the general user base sooner.

To be complete my comments above are based on trunk r46451 of MacPorts.

[jmroot (Joshua Root)]

That doesn't look like trunk output for port deps. Here, with an empty variants.conf:

% port deps gtk2
Full Name: gtk2 @2.14.7+x11
Build Dependencies:   pkgconfig, gtk-doc
Runtime Dependencies: shared-mime-info
Library Dependencies: cairo, fontconfig, freetype, glib2, jpeg, tiff, libiconv,
                      libpng, jasper, atk, pango, gettext,
                      zlib, xorg-libXi, xorg-libXrandr,
                      xorg-libXcursor, xorg-libXinerama,
                      xorg-libXdamage, xorg-libXcomposite,
                      xorg-libXfixes

And with +no_x11 in variants.conf:

% port deps gtk2
Full Name: gtk2 @2.14.7+no_x11+quartz
Build Dependencies:   pkgconfig, gtk-doc
Runtime Dependencies: shared-mime-info
Library Dependencies: cairo, fontconfig, freetype, glib2, jpeg, tiff, libiconv,
                      libpng, jasper, atk, pango, gettext,
                      zlib

[gwhitney]

Indeed, trunk/base/src does not contain the string "dependencies on" -- it was removed in r44362. So, devans, please could you try rebuilding/reinstalling port from trunk and see if the problem goes away?

[dbevans (David B. Evans)]

Yes, apparently I was NOT using trunk after all. After installing the real trunk version, all the problems went away as one might expect. So closing this one again. Sorry for the false alarm.

[adambyrtek@…]

Will it be included in 1.7.1? It is even more important now, when more and more people tend to use "no_x11" variant due to the fact that dependencies on Xorg have been added to many ports instead of relying on X11 from OS X.

[adambyrtek@…]

Cc Me!

[list-ener@…]

Cc Me!

[coda.hale@…]

Cc Me!

[mjs@…]

Cc Me!