On 04.04.2012, at 23:20, Jan Stary wrote: > On Apr 04 16:05:27, Jeremy Lavergne wrote: >>> "/usr/local is not a viable choice because some software >>> (especially auto* tools from Gnu) look in /usr/local >>> as a default location, which means MacPorts can't be >>> easily isolated when needed." >>> >>> I want to kindly ask the person who wrote this to elaborate, >>> and be as specific as can be: what exactly does it mean for macports >>> to be "isolated", and how exactly does e.g. auto* looking into >>> /usr/local stand in the way of it? >> >> As with the software that magically found its way into /usr/local, how do we >> stop that very same software from clobbering what MacPorts has installed >> there? > > You keep saying that: "the software that magically finds its way to > /usr/local". What do you even mean by that? The user installed it > there; that's about the only way something gets into /usr/local. > > And how do we stop the user from rewriting something that is already there? > We don't, and we can't. It's the user's responsibility to not be an idiot > and rewrite something he has installed himself before. > > In fact, what difference does "/usr/local or /opt/local" > (or any ther prefix for that matter) make in this respect? > In the current state of things, how do you stop the user > from overwriting something that macports has installed under > /opt/local? > > You don't, because you can't. It's the user's responsibility > to not install over something that is already installed > (whatever the prefix is).
All kinds of software do actually install their stuff in /usr/local on OS X. Examples are a libpng framework from http://ethan.tira-thompson.com/Mac_OS_X_Ports.html or the Sane packages you get through following the links on the official sane site (that's the two things that *magically* ended up in my /usr/local). The problem is that a couple of packages just install to /usr/local without explicitly stating that or giving the option to use another prefix. This is something you can't avoid and would mess up MacPorts if it were to use /usr/local (the index of installed ports would no longer match what is *really* there because some software overwrites the existing libs and includes - making it worse by not honoring what the macports user wanted if he chose universal builds, etc...). Not many packages will use /opt/local, the few that do seem to be by rookie packagers that used a MacPorts base to build their package. Never encountered one of those yet. So in the above example this can mess up MacPorts builds when a port relies on libpng and wants the up to date libpng but is forced to use whatever version that is installed in /usr/local because the compiler defaults to that one. Alltogether I wonder what your aim is anyway, you won't change the developers decision to change the prefix after years of using that. Dom _______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
