[MacPorts] #18149: coreutils +with_default_names vs. gettext vs. MacPorts (was: gettext @0.17_3 fails with coreutils +with_default_names)

[MacPorts]

#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