/usr/local question

Jan Stary hans at stare.cz
Wed Apr 4 15:19:50 PDT 2012


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

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

> > "/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).

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

(I'm not saying it doesn't; it's an honest question.)

> "/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:
everything goes under /usr/local. I still don't see how
that would be wrong here (besides a user himself stupidly
rewriting things).

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

> > 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.
(Not a very good one.) Does that prohibit me from /usr/local? No.

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.

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?

> No package system should be touching /usr/local.

Where did you get this? No really, where does this come from?

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

(No irony here. I really want to know, and appreciate the
time you spent answering my doubts.)



More information about the macports-users mailing list