/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