/usr/local question

[Christopher Vance]

So /usr/local is kept hostage by crap GNU tools.

I do note that most Linux distros manage to convince even GNU crapware to install somewhere outside /usr/local. I'd be surprised if they permitted their builds to get distracted by stuff in /usr/local. But then they tend (Gentoo excepted) to provide prebuilt packages, rather than expecting you to build from source. Maybe their solution is purely to build on systems with empty /usr/local.

I'm guessing that some of the errant GNUware could be fixed by source patches which upstream might refuse to apply. Do we have such patches available?

I'm guessing that the rest probably require source fixes and recompiling everything else GNU that's broken, including compilers, binutils, etc. These build-essential ports should perhaps be made available as compiled packages, rather than expecting people to bootstrap their own from source.

I'll mention that NetBSD has used /usr/pkg for ages, rather than /usr/local, and is having a bunfight/bikeshed about the few remaining packages that insist on trashing the file system before a package can be made. Most of their package builds now do a staging install outside the final resting place before making a package, and that you then use the package to install from.

Maybe they have patches available to prevent poisoning from /usr/local? I believe they use their prerequisite feature to ensure that the required ports are already installed in /usr/pkg, and tweak ./configure arguments to know the directories they are in.

I'll also mention that OpenBSD exclusively uses packages which are compiled elsewhere; all ported software is installed from packages; they have already reached where NetBSD is trying to get to. In addition, OpenBSD culture is to install from packages, not by building from source yourself.

Maybe they have patches which prevent GNU crapware from inspecting bogus locations before building packages? OpenBSD also uses prerequisite packages and configure tweaks to ensure that the stuff they use is installed in /usr/local from OpenBSD packages, and to use the required directories installed from those packages.

Macports is the only software packaging system I follow which seems to suffer from /usr/local issues. This is a pity, since I use it on my main development system, and I can't afford the Apple tax to buy a separate Apple machine (without /usr/local) just to build ports on. I can't believe that this problem hasn't already been solved on some of the OSs and packaging systems I've mentioned.

But in the end, I will support those who do development on Macports by acknowledging that they don't have excess capacity. We'd rather they be porting or updating the stuff we actually want to use, rather than spend their effort fixing all the GNU crap used to build them.

-- Christopher

On 05-Apr-2012, at 18:12 , Jan Stary wrote:

>> I agree now that /usr/local is on fact a bad choice.
>> What I find cnfusing or unclear is the reasoning about it
>> in the the FAQ.
>> 
>> The most prominent reason given to me yesterday for not having
>> /usr/local as a default prefix was that people will stupidly
>> rewrite the stuff in there by blindly clicking through third-party
>> installers. That for example is not mentioned in the FAQ at all.
> 
>> I will try to come up with a better reformulation based
>> on what people have explained to me here.
> 
> 
> OK, here is what I propose as a relacement/extension of FAQ#defaultprefix.
> Does this correctly describe the reasoning that was kindly explained
> to me in the previous discussion? Obviously, I would like this OK'd here
> before I mangle the wiki.
> 
> (The XXX is where my English fails me. Could a native speaker
> put the right verb in please that seems to slip my mind?)
> 
> 
> * Why is /opt/local the default install location for MacPorts?
> 
> Traditionally, the place to install third party software on many UNIX systems
> is /usr/local. However, having macports under /usr/local would be error-prone.
> Many other software packages and packaging systems install in there, and
> would accidentaly overwrite what macports has installed, or vice versa.
> While this could be XXXed off as the user's own error, it is a fact that
> users click through installers blindly, and consequently collisions under
> /usr/local (and other prominent directories) happen very often.
> Macports doesn't want to be a victim of that, and /opt/local provides
> the splendid isolation - as would any other dedicated directory, of course.
> Also, /usr/local is traditionally reserved for the given system's admin
> to install local tools; macports doesn't want to stomp on that either.
> 
> (For the same reasons, fink uses /sw as its prefix.)
> 
> 
> * So with macports under /opt/local I can use /usr/local freely?
> 
> No, not entirely. Even with macports living elsewhere, /usr/local
> can still interfere. Some software (especially the GNU auto* tools
> and gcc) looks into /usr/local for external headers, libraries,
> and binaries. Ceratin ports might (and do) fail to build because
> during their build something incompatible is found and picked up
> from /usr/local. Good ports avoid this by explicitly specifying
> --with-libfoo=/opt/local/lib/ or explicitly disabling all such
> possible dependencies altogehter with --disable-foo or --without-bar,
> but not all ports are able to do that.
> In some cases, it might even be necessary to
> temporarily make /usr/local disappear entirely for a given port
> to build successfully. Obviously this wouldn't be possible if
> macports itself lived under /usr/local.
> 
> (And a third which I don't expect to be let through:
> 
> * So in order to build a given broken port with macports,
>  you advice me to remove /usr/local altogether, thus
>  crippling my system for the duration of the build?
> 
> Sadly, yes.)
> 
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-users