Opened 16 years ago

Closed 15 years ago

#18149 closed defect (fixed)

coreutils +with_default_names vs. gettext vs. MacPorts

Reported by: macports@… Owned by: macports-tickets@…
Priority: Normal Milestone: MacPorts 1.8.0
Component: base Version: 1.7.0
Keywords: Cc: nox@…, ryandesign (Ryan Carsten Schmidt), jmroot (Joshua Root)
Port: gettext, coreutils

Description

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

Change History (7)

comment:1 Changed 16 years ago by jmroot (Joshua Root)

Owner: changed from macports-tickets@… to ryandesign@…
Port: gettext added

comment:2 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: nox@… ryandesign@… added
Component: portsbase
Milestone: Port BugsMacPorts Future
Owner: changed from ryandesign@… to macports-tickets@…
Port: coreutils added
Summary: gettext @0.17_3 fails with coreutils +with_default_namescoreutils +with_default_names vs. gettext vs. MacPorts

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 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?

comment:3 Changed 16 years ago by jmroot (Joshua Root)

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

comment:4 in reply to:  2 Changed 16 years ago by macports@…

Replying to 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.

comment:5 in reply to:  3 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to 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.

comment:6 Changed 15 years ago by jmroot (Joshua Root)

Cc: jmr@… added

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?

comment:7 Changed 15 years ago by jmroot (Joshua Root)

Milestone: MacPorts FutureMacPorts 1.8.0
Resolution: fixed
Status: newclosed

Assuming this is fixed, in the absence of evidence to the contrary.

Note: See TracTickets for help on using tickets.