[MacPorts] #18149: gettext @0.17_3 fails with coreutils +with_default_names
#18149: gettext @0.17_3 fails with coreutils +with_default_names -------------------------------------+-------------------------------------- Reporter: macports@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.7.0 Keywords: | Port: -------------------------------------+-------------------------------------- {{{ ---> Deactivating gettext @0.17_3 Error: Deactivating gettext 0.17_3 failed: Error: Unable to upgrade port: dyld: Library not loaded: /opt/local/lib/libintl.8.dylib Referenced from: /opt/local/bin/ln Reason: image not found Error: No ports found }}} /bin comes before /opt/local/bin in my $PATH. Specify /bin/ln or at least respect my environment. -- Ticket URL: <http://trac.macports.org/ticket/18149> MacPorts <http://www.macports.org/> Ports system for Mac OS
#18149: gettext @0.17_3 fails with coreutils +with_default_names -------------------------------------+-------------------------------------- Reporter: macports@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.7.0 Keywords: | Port: gettext -------------------------------------+-------------------------------------- Changes (by jmr@…): * owner: macports-tickets@… => ryandesign@… * port: => gettext -- Ticket URL: <http://trac.macports.org/ticket/18149#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS
#18149: coreutils +with_default_names vs. gettext vs. MacPorts -------------------------------------+-------------------------------------- Reporter: macports@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts Future Component: base | Version: 1.7.0 Keywords: | Port: gettext, coreutils -------------------------------------+-------------------------------------- Changes (by ryandesign@…): * cc: nox@…, ryandesign@… (added) * component: ports => base * milestone: Port Bugs => MacPorts Future * owner: ryandesign@… => macports-tickets@… * port: gettext => gettext, coreutils Comment: MacPorts deliberately does not respect your environment and instead uses the value of the `binpath` variable. It can be changed in `${prefix}/var/macports/macports.conf` but doing so is discouraged. Many ports assume the MacPorts paths are first in the `binpath`. The problem of coreutils +with_default_names vs. gettext vs. MacPorts was recently [http://lists.macosforge.org/pipermail/macports- users/2009-January/013330.html brought up on the macports-users mailing list] as well. It's not the gettext port's fault. It's not doing anything special here. It's MacPorts base that's wanting to use a utility called `ln` to perform the normal task of deactivating and activating ports. And unfortunately coreutils +with_default_names provides a utility called `ln`, and it's linked with gettext. So as soon as gettext gets deactivated, `ln` no longer works and MacPorts base breaks. On the mailing list I suggested that the coreutils port could remove its +with_default_names variant, and/or MacPorts base could use `/bin/ln` absolutely and not attempt to use a version installed by MacPorts. Actually it surprises me that MacPorts base is shelling out to an `ln` command at all; why aren't we using the `[file link]` Tcl command? -- Ticket URL: <http://trac.macports.org/ticket/18149#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS
#18149: coreutils +with_default_names vs. gettext vs. MacPorts -------------------------------------+-------------------------------------- Reporter: macports@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts Future Component: base | Version: 1.7.0 Keywords: | Port: gettext, coreutils -------------------------------------+-------------------------------------- Comment(by jmr@…): I fixed a handful of this stuff in r45851. There are valid reasons for calling out with system/exec sometimes, for example `file delete` doesn't handle directories on Panther, and `file link -symbolic` won't let you link to a file that doesn't exist. There are still quite a lot of places where bare command names are being used, and they should be converted to use full paths, preferably as detected by autoconf (and falling back on binaryInPath). These are the ones I found: {{{ bunzip2 chmod chown curl diff dscl file find gunzip gzip id lipo patch tar touch xcodebuild }}} At first glance it seems like all of them should be converted so that broken ports can't break base. But we should be careful of problems like what happened with svn (#15868). -- Ticket URL: <http://trac.macports.org/ticket/18149#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS
#18149: coreutils +with_default_names vs. gettext vs. MacPorts -------------------------------------+-------------------------------------- Reporter: macports@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts Future Component: base | Version: 1.7.0 Keywords: | Port: gettext, coreutils -------------------------------------+-------------------------------------- Comment(by macports@…): Replying to [comment:2 ryandesign@…]:
On the mailing list I suggested that the coreutils port could remove its +with_default_names variant Two wrongs don't make a right.
-- Ticket URL: <http://trac.macports.org/ticket/18149#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS
#18149: coreutils +with_default_names vs. gettext vs. MacPorts -------------------------------------+-------------------------------------- Reporter: macports@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts Future Component: base | Version: 1.7.0 Keywords: | Port: gettext, coreutils -------------------------------------+-------------------------------------- Comment(by ryandesign@…): Replying to [comment:3 jmr@…]:
I fixed a handful of this stuff in r45851. Thanks! I see you did some more in r45990. Have you already tested whether MacPorts now works with a busted coreutils installed?
There are valid reasons for calling out with system/exec sometimes, for example `file delete` doesn't handle directories on Panther, and `file link -symbolic` won't let you link to a file that doesn't exist. That explains it, thanks.
At first glance it seems like all of them should be converted so that broken ports can't break base. But we should be careful of problems like what happened with svn (#15868). I agree that svn should use the MacPorts version if available, but that the others should use only the system versions.
-- Ticket URL: <http://trac.macports.org/ticket/18149#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS
#18149: coreutils +with_default_names vs. gettext vs. MacPorts -------------------------------------+-------------------------------------- Reporter: macports@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts Future Component: base | Version: 1.7.0 Keywords: | Port: gettext, coreutils -------------------------------------+-------------------------------------- Changes (by jmr@…): * cc: jmr@… (added) Comment: This should no longer be an issue in current trunk, but I don't really want to install coreutils+with_default_names to check. Anyone able to confirm? -- Ticket URL: <http://trac.macports.org/ticket/18149#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS
#18149: coreutils +with_default_names vs. gettext vs. MacPorts --------------------------------------+------------------------------------- Reporter: macports@… | Owner: macports-tickets@… Type: defect | Status: closed Priority: Normal | Milestone: MacPorts 1.8.0 Component: base | Version: 1.7.0 Resolution: fixed | Keywords: Port: gettext, coreutils | --------------------------------------+------------------------------------- Changes (by jmr@…): * status: new => closed * resolution: => fixed * milestone: MacPorts Future => MacPorts 1.8.0 Comment: Assuming this is fixed, in the absence of evidence to the contrary. -- Ticket URL: <http://trac.macports.org/ticket/18149#comment:7> MacPorts <http://www.macports.org/> Ports system for Mac OS
participants (1)
-
MacPorts