#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