New Ticket     Tickets     Wiki     Browse Source     Timeline     Roadmap     Ticket Reports     Search

Ticket #8221 (closed enhancement: fixed)

Opened 7 years ago

Last modified 4 years ago

RFE: port upgrade should consider variants when computing dependencies

Reported by: ryandesign@… Owned by: gwhitney@…
Priority: Normal Milestone: MacPorts 1.8.0
Component: base Version:
Keywords: Cc: ryandesign@…, jmr@…, vinc17@…, aetherknight@…, korpios@…, devans@…, adambyrtek@…, list-ener@…, coda.hale@…, mjs@…
Port:

Description (last modified by ryandesign@…) (diff)

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.

Attachments

upd.patch (11.0 KB) - added by gwhitneycom1@… 6 years ago.
Proposed patch against r25313 to resolve this issue
upgrade-variants-man.diff (762 bytes) - added by jmr@… 5 years ago.
updated man page section of the patch
upgrade-variants.diff (10.5 KB) - added by jmr@… 5 years ago.
updated patch against current base

Change History

comment:1 Changed 7 years ago by dluke@…

  • severity changed from normal to enhancement
  • Summary changed from port upgrade should consider variants when computing dependencies to RFE: port upgrade should consider variants when computing dependencies

Changed 6 years ago by gwhitneycom1@…

Proposed patch against r25313 to resolve this issue

comment:2 Changed 6 years ago by 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.

comment:3 Changed 6 years ago by ryandesign@…

  • Owner changed from macports-tickets@… to gwhitney@…
  • Cc ryandesign@…, gwhitney@… added
  • Component changed from ports to base

comment:4 follow-up: ↓ 5 Changed 6 years ago by nox@…

  • Priority changed from Expected to Normal
  • Version 1.2 deleted
  • Milestone set to MacPorts base bugs

This is not anymore relevant, is it?

comment:5 in reply to: ↑ 4 Changed 5 years ago by jmr@…

  • Cc jmr@… added; gwhitney@… removed

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?

Changed 5 years ago by jmr@…

updated man page section of the patch

Changed 5 years ago by jmr@…

updated patch against current base

comment:6 Changed 5 years ago by ralph@…

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

comment:7 Changed 5 years ago by ryandesign@…

  • Description modified (diff)
  • Reporter changed from opendarwin-2006@… to ryandesign@…

comment:8 Changed 5 years ago by bcbarnes@…

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

comment:9 Changed 5 years ago by blb@…

  • Milestone changed from MacPorts base bugs to MacPorts 1.8.0

comment:10 Changed 4 years ago by vinc17@…

  • Cc vinc17@… added

Cc Me!

comment:11 Changed 4 years ago by devans@…

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).

comment:12 Changed 4 years ago by aetherknight@…

  • Cc aetherknight@… added

Cc Me!

comment:13 Changed 4 years ago by aetherknight@…

  • Cc aetherknight@… removed

Cc Me!

comment:14 Changed 4 years ago by aetherknight@…

  • Cc aetherknight@… added

Cc Me!

comment:15 Changed 4 years ago by korpios@…

  • Cc korpios@… added

Cc Me!

comment:16 Changed 4 years ago by 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". :/

comment:17 Changed 4 years ago by gwhitney@…

  • Status changed from new to closed
  • Resolution set to fixed

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.

comment:18 Changed 4 years ago by devans@…

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?

comment:19 Changed 4 years ago by devans@…

  • Cc devans@… added

Cc Me!

comment:20 Changed 4 years ago by devans@…

  • Status changed from closed to reopened
  • Resolution fixed deleted

comment:21 Changed 4 years ago by devans@…

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.

comment:22 Changed 4 years ago by jmr@…

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

comment:23 Changed 4 years ago by 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?

comment:24 Changed 4 years ago by devans@…

  • Status changed from reopened to closed
  • Resolution set to fixed

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.

comment:25 Changed 4 years ago by 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.

comment:26 Changed 4 years ago by adambyrtek@…

  • Cc adambyrtek@… added

Cc Me!

comment:27 Changed 4 years ago by list-ener@…

  • Cc list-ener@… added

Cc Me!

comment:28 Changed 4 years ago by coda.hale@…

  • Cc coda.hale@… added

Cc Me!

comment:29 Changed 4 years ago by mjs@…

  • Cc mjs@… added

Cc Me!

Note: See TracTickets for help on using tickets.