/usr/local question

Dominik Reichardt domiman at gmail.com
Wed Apr 4 15:03:54 PDT 2012


On 04.04.2012, at 23:48, Jan Stary wrote:

> On Apr 04 23:32:26, Dominik Reichardt wrote:
>> 
>> 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
> 
> (1) Why would anyone use this when libpng is in macports?

Because not everybody is using their mac as you do. I needed the *framework* to provide macports independent snapshots of a game engine and to give people *easy* instructions that do not involve getting macports

> (2) The site itself says "You will have the opportunity to select
> [the destdir] during installation".
> 

that you can select the destination dir seems new to me. Since I'm only using an older package that included ppc arch I no longer keep up to date with this.

>> or the Sane packages you get through following the links
>> on the official sane site
> 
> (1) Why would you use this when sane is in macports?

Independence of macports.

> (2) http://ljm.home.xs4all.nl/SANE-faq.html#35
> 	"SANE sits under /usr/local."
> 
>> (that's the two things that *magically* ended up in my /usr/local).
> 
> No it didn't magically ended up there. You installed it there.
> And you were told before you installed it there that it will
> end up there.

I didn't say that, I said *magically*. Of course I know there was no magic involved. Phew...

> 
> I see what you mean, but none of those is an example.
> 

If you see what I mean why are you a ... about it? I'm not trying to get into a wise guy discussion. If *you* want this, let me know so I can let you talk to yourself.

>> 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.
> 
> That's right. With /opt/local you can't avoid it ether, can you?

No, but no software I know about is actually doing it.

> 
>> So in the above example this can mess up MacPorts builds when a port
>> relies on libpng and wants the up to date libpng
> 
> When a port requires libpng, it says so in its Portfile;
> and macports will install libpng (as present in macports,
> not http://ethan.tira-thompson.com/Mac_OS_X_Ports.html)
> as a dependency.

You don't seem to understand. 
Of course MacPorts WILL install libpng in /opt/local and not http://ethan.tira-thompson.com/Mac_OS_X_Ports.html (I'm wondering what gave yu the impression that I thought MacPorts would do this...)
But when the port that requires libpng is then built the compiler may chose the libpng that got installed in /usr/local. I don't know what triggers this, I guess all ports that use autotools and/or libtool might not fall in that trap or I'd have stepped into that pile before.


Dom




More information about the macports-users mailing list