/usr/local question

[Dominik Reichardt]

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