coreutils +with_default_names vs. gettext vs. MacPorts

[macports@…]

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

[ryandesign (Ryan Carsten Schmidt)]

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?

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

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

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

[jmroot (Joshua Root)]

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?

[jmroot (Joshua Root)]

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