/usr/local question

Wed Apr 4 18:16:04 PDT 2012

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

> > 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?
>
> Oh I am aware of it, and specifically mention it about
> two lines below the point where you cut my message, as you know.
>

Yes, so why are you so confused about 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).
>
> Do you mean that someone uses, say, both macports and fink?
>

Or macports and homebrew, or fink and homebrew, absolutely yes.  It's a bad
idea but it's a common one (and one which homebrew tries to encourage,
often with very unfortunate results, although I gather they're learning the
hard way the lesson you seem to be going out of your way to not figure out).

>
> > > "/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.
>
> Yes, I understand this. What I don't understand is how
> having /opt/local as a prefix makes this better than
> having /usr/local (or whatever else).
>

That is extremely evident.

If I keep MacPorts in its own prefix, it is easier to ensure that other
software on my system does not get mixed up in a build.  As a port
maintainer, this means I can produce a port that does not accidentally
depend on software that MacPorts doesn't know about, which would lead to
other people who try to install my port getting unexpected errors because
they don't have that software installed, or (much harder to diagnose) have
the wrong version of it installed.

>
> > Isolation of the package system is part of what makes this possible.
>
> In what way exactly does having /opt/local make this possible
> as opposed to having /usr/local, which would not make it possible?
>

Because, as you repeatedly point out, *other* software (not related to
MacPorts) is also installed in that location.  If it's all intermingled, I
can't reliably keep it from being found and used when building software for
MacPorts.  If MacPorts is in its own tree, I can at absolute worst move
other trees to archival storage (but usually just rename them to something
that won't be searched automatically the way /usr/local is) and now I can
do a build which I *know* doesn't depend on some other software I'd
forgotten about.  This is important if I intend that build (or in the case
of MacPorts, the Portfile that does the build) to be usable by other people
on random other machines.

This is what "repeatable build" is about.

> > "/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.
>
> This is exactly how OpenBSD's pkg_add works, for example:
>

I know; FreeBSD ports does the same thing.  And it causes problems quite
often when third party packages are also installed under /usr/local.
 MacPorts changed to /opt/local in part *because* of that experience; I
suspect the BSDs would change as well if it wouldn't cause significant pain
to users.

> > You are misunderstanding the point here completely.  /usr/local is
> > specifically intended to be left alone by *any* package system.  This
> > includes MacPorts.
>
> Where did you get this?
> This is what hier(7) says about /usr/local on my 10.5.8:
>
>         executables, libraries, etc.
>         not included by the basic operating system
>
> How does that exclude stuff from any package system?
>

This is based on the BSD model, which as I just described above is actually
fairly broken.  See for comparison what Linux's FHS has to say about it
(FHS also learned from BSD's mistake).

When I described repeatable builds above, I explained in practice why this
distinction is important.

> > > 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.
>
> Me doing './configure ; make ; make install' is a package system.
>

You have an odd definition of "package system", then, which does not match
the one that is in common use.  If you're going to quibble on definitions
then this discussion will go precisely nowhere.

Compiling something with macports (or fink or whatever)
> IS building it myself - except I didn't type the 'make'

command with my fingers, it was read from a template.
>

In some sense it is, if you want to be brutally and uselessly pedantic,
yes.  The question is, do you expect it to work exactly the same way as the
configure;make;make install method does, or do you have some different
expectation?

Most people expect fink or macports, etc. to

1. ensure that all dependencies are present
2. ensure that no conflicting packages are present
3. keep track of the installation so that it can be uninstalled or upgraded
as necessary

(This, btw, is a minimal definition of "package system" as used previously.
 Again, if you do not accept this definition, then the discussion is over;
you want something that is not MacPorts or Fink, and I suggest you simply
install all your own software instead of trying to force MacPorts to stop
being a package system.)

Whereas with the configure;make;make install method, all of that is on you
to deal with.

If I manually followed all the steps that macports does
> when building a package, would I be bulding it myself?
> As "opposed" to having it built by macports?
>

This only makes sense to me if you think "all the steps" are
configure;make;make install.  Then again, it's also clear you don't think
keeping track of install locations and versions has any value whatsoever,
so maybe that *is* "all the steps" to your mind; again, this means you do
not want MacPorts.

> > No package system should be touching /usr/local.
>
> Where did you get this? No really, where does this come from?
>

Years of experience by most people who have to manage anything larger than
their one home system, as incorporated into such documents as Linux FSSTND.

> 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.
>
> That's right: I don't understand how having a default prefix
> of /opt/local (or /something/deffinitely/other/than/usr/local)
> ensures that.
>
> > Ironically, making the changes you
> > claim are the only way that makes sense would probably result in MacPorts
> > being unusable for you.
>
> Show me. If the default prefix changed to /usr/local,
> what exactly would break for me?
>

I hope I answered this sufficiently above.

If I haven't, then suffice it to say that MacPorts is not for you and you
should stick to installing your own software.

-- 
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/f4950581/attachment.html>