/usr/local question

[Jan Stary]

The more I think about it, the more I tend to this conclusion:

Using /opt/local as the default prefix is an attempt
to save the user from himself, which is pointless.
Any other benefits it has would also be present
if the default prefix was /usr/local.

Please bare with me and wait with the stoning.

First, let me go through the reasons we currently
do NOT use /usr/local as the default prefix, as
described in the FAQ:


(1)
"/opt/local was chosen so as to avoid stomping on other various installations"

What "other various installations", exactly?
Nobody uses more then one port system on a given machine
(not that know about any other beside macports and fink).
So whatever the macports prefix, it will not stomp on
any other port system's installations (or vice versa),
because there is no other port system in use. That leaves
- the MacOS isntallation as shipped by Apple
- manual installations done by the user

As agreed before, MacOSX itself doesn't install nothing under /usr/local.
That leaves only the user manually installing stuff under /usr/local
(as usual on many UNIXes). The only way these installations would
"stomp on each other" is if the user either installs something from macports
and later overwrites it with a manual installation, or vice versa.
That's the user's obvious and stupid error.

Retreating from /usr/local in the sense of (1) is nothing else
than trying to protect the user from himself. I think that't pointless.


(2)
"/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?

Does the "isolation" here mean that the libraries, headers, etc
as installed from macports should be distinguishable by third-party
software as such (i.e., as installed by macports, and no other)?

Indeed, the auto* tools and other software (gcc?) look into /usr/local. 
That's not a reason to NOT install our stuf in there. On the contrary,
that's a reason to install in there, as ubiquitous tools such as 
auto* and pkgconfig and gcc WILL FIND IT THERE when installing other
software later.

In fact, that's one of the reasons people do install software:
so that it is found and used by other software. Example: if, say,
libsndfile is installed under /usr/local, compiling any other
audio software later will find it there BY DEFAULT and use it,
WHICH IS WHY I installed it in the first place.


(3)
"/usr/local is not a viable choice because it is usually reserved
for the given system's admin to install items local to that system,
and tends to be a bad choice to have taken over by a non-system port system".

Yes, /usr/local i traditionaly used to install items local to that system.
How does it make it a bad choice for the macports prefix?
The stuff I install from macports IS local to that system!

Also, it's not macports "taking over" /usr/local.
The user takes over /usr/local (as intended for ages),
be it via manual installation or macports or anything else.


(4)
"/usr/local is not a viable choice because gcc considers /usr/local
to be a standard system directory, causing (at least) the include
directory to be unable to appear early in the list of include directories,
and hence causing MacPorts-installed items to be difficult to use properly
for items which need them (where another version is installed elsewhere,
like /usr/X11R6)"

Yes, gcc considers /usr/local to be a standard directory;
it is searched for headers and libs and binaries. How does that make
"the include directory" (which? /usr/local/include?) not able to appear
early in the list of include directories? On the contrary, being
considered a standard system directory, it appers in the list
prominently. If macports installed stuff under /usr/local,
how exactly would make it "difficult to be used properly"?




On Apr 04 11:26:14, Jeremy Lavergne wrote:
> /usr/local is horrible because it takes precedence
> over everything else on your system

Yes, it takes precedence. That's the point: to have a place where
things are supposed to be installed. Why does it make /usr/local "horrible"?
How would that be less "horrible" if it was any other directory?

> This means incorrect libraries and headers
> that magically find their way in there via other installers
> will be used instead of the software that was actually intended.

Whoa, stop right there. This paragraph makes no argument against /usr/local,
it's just dissing it with meanlessly negative adjectives.

(*) What "incorrect libraries and headers"?
The headers and libraries I install under /usr/local (or anywhere else,
for that matter) manually (or any other way, for that matter)
are no more or less "correct" than those installed by macports
(or any other installer, for that matter).

(*) How exactly do they "magically find their way" into /usr/local?
The user installs it there!

(*) Yes, the stuff under /usr/local will be used then.
That's why the user installed it in there; because
that's what he "actually intended".


> > I use Linux extensively for my servers and Macs when I'm trying to be a human. /usr/local has been around for quite a while in the *nix world (it's even in the default $PATH), and I use it a little on the Macs. I can't think of what the problem is -- (seems to) work fine here :-)
> 
> Because /usr/local is searched by default by the compiler
> and we do not know how to turn that off,
> MacPorts ports might try to link with libraries
> you've installed in /usr/local. 

This is exactly what got me thinking:
Yes, it is searched by the compiler, but why would I want to turn that off?
Yes, macports might try to link against stuff under /usr/local,
but that's only a problem if macports' own stuff IS NOT that under /usr/local.


> This might be overkill, but have you considered adding code to your scripts
> to mv /usr/local to /usr/localqw (and back at the end)?
> Or maybe just the lib dir?

Thus crippling all my manual installations,
such as the backup cronjob script that was about to run,
(before the electricity dies out an hour from now)?


> The definition of /usr/local is a directory where users put things
> they've compiled themselves; things that did not come from the OS vendor.

EXACTLY - such as the macports stuff! That's what I have compiled myself
(with the help of a Portfile); that's what did not come from the OS vendor.
See?


> Therefore it is right for Apple to not ship anything in /usr/local,
> and it's perhaps even reasonable for them to ship a compiler that
> looks there for dependencies.

Yes. That's why we want to have our stuff there.

> I didn't think this was an Apple-specific thing;
> I thought that's just how GCC works, but I don't know for sure.

I think you are right: that's a gcc thing.

> I think the user needs to be the one to understand the consequences
> of their actions of installing things in /usr/local and be the one
> to take responsibility for uninstalling those items.

I completely agree: it's the user's responsibility.
There is no point retreating from /usr/local just to
ease the user from this responsibility.

> Not everything in /usr/local is necessarily a problem.
> But we do not want to spend our time analyzing what rogue software
> is and isn't a problem;

Again, this is just bad-mouthing. Why would anything under /usr/local
(or anything outside of macports) BE a problem, solely on the grounds
it is under /usr/local? Really? What "rogue software"?

> we have real actual MacPorts issues that we want to spend our time solving that don't involve rogue software. If a user reports a problem, and the error message or log contents point to something existing in /usr/local, our response will be to make the user remove /usr/local and try again.

If that something exsist under /usr/local, it is there because the user
wants it there. MAcOSX itself didn't put it there; macports didn't put
it there. It is solely the user's explicit desire to have that thing
installed. Just telling the user to remove it is silly.

If it is a prerequisite for macport to function properly
that /usr/local does not exist, then macports might
as well make /usr/local its own prefix (as anything
else is prohibited to even exist there anyway, right?)


> >> I don't install things there, but there are things in there
> >> (mostly from Mac OS) that I'd like to keep and use.
> > 
> > is there a recommended place for me to put these programs?
> 
> Any other place on the hard drive that doesn't already have a defined meaning. So any prefix other than /, /usr, /usr/local, /opt/local or /sw should be fine. 
See, this makes no sense either. Yes, /usr/local already has a defined
meaning: to hold the software local to this system. That's exactly why
I will install it THERE.


> If you want to install in directories other than /usr/local to avoid any
> conflicts with Mac Ports, you could use the other *nix location $HOME/bin.

That would only make it available to me. I want the installed software
to be available to all users.

> You'd probably have to create the directory in /Users/yourname

Huh? That's my $HOME, which obviously exists already.

> `PATH=$PATH:$HOME/bin`

That puts it last in the path, which is probably
not what you intended.

> On Apr 4, 2012, at 10:55, Jan Stary wrote:
> > In fact, I believe it is a good candidate for a FAQ immediately
> > following https://trac.macports.org/wiki/FAQ#defaultprefix:
> > Q: "So given that macports uses /opt/local as its prefix,
> > I can use /usr/local freely without worying about interference?"
> > A: No, not really. (etc)

> I'd really like to see an expansion of that "etc". 

Well, obviously. I want to clear this for myself
(and possibly others) before caughing up a formulation.

> The wiki is editable by everybody; feel free to add this.

(... let alone mangling the wiki with something that's not
yet agreed upon :-)


Perhaps this is the right place to think Jeremy and Ryan and the others
for making macports happen in the first place. I hope this comes over
as politely as it is intended. I genuinely do think that /usr/local
would be a better prefix.

Please point to where I am wrong,
and please be very specific and give examples.

	Sincerely

		Jan