/usr/local question

[Brandon Allbery]

Too many outright errors.  Please.

On Wed, Apr 4, 2012 at 17:01, Jan Stary <hans at stare.cz> wrote:

> "/opt/local was chosen so as to avoid stomping on other various
> installations"
>
> What "other various installations", exactly?
>

Any software not part of a package system such as Apple's own, Fink,
MacPorts, Homebrew, etc.  A highly incomplete ist of specific examples:

- Growl extensions (specifically growlnotify installs there)
- The official Haskell Platform installer
- The official TeXLive installer

It's the usual Unixy place for third party software, a point you yourself
made at some point; how is it you are now unaware of it?


> Nobody uses more then one port system on a given machine
>

Excuse me?  Conflicts between the various installer systems happen fairly
often, because people *do* try to use multiple installer systems --- as
well as third party software independent of them (as above).


> "/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?
>

So, are you at all familiar with the concept of "repeatable builds"?  It is
something which has particular importance in the world of packaging
systems:  it means, among other things, that you can ensure that a package
builds the same way and runs the same way on as many systems as possible.
 MacPorts would not be particularly useful if a port only built properly on
its maintainer's machine.

Isolation of the package system is part of what makes this possible.

"/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!
>

By that same argument, installing anything via apt-get or yum on Linux
should install to /usr/local because you're only installing it locally.

You are misunderstanding the point here completely.  /usr/local is
specifically intended to be left alone by *any* package system.  This
includes MacPorts.


> > 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.
>

If you still believe this, reread my previous statements until you
understand them.

> 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?
>

You have lost track of MacPorts being a package system.  If you built it
yourself, not as part of a package system, that's what /usr/local is for.
 No package system should be touching /usr/local.

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"?
>

...and the fact that you keep repeating this indicates to me that you are
not at all experienced in the concept of packaging, or package systems.
 You know about your own machine, you only care about your own machine;
this is fine for you, but you fail to understand that the restrictions
MacPorts operates under ensure that it will work on your machine instead of
just the port maintainer's machine.  Ironically, making the changes you
claim are the only way that makes sense would probably result in MacPorts
being unusable for you.

(I am, by the way, seriously considering saving your message as a near
perfect example of why developers so often produce code that works on their
development machines but not in production.)

-- 
brandon s allbery                                      allbery.b at gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20120404/9db90ef1/attachment.html>