/usr/local question

[Jan Stary]

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

No, not really. You have macports stuff in its own prefix, namely,
/opt/local. However, if a given port silently picks up something
incompatible in /usr/local, if might fail and often will.

Having macports isolated in /opt/local DID NOT save you from this.
Removing /usr/local is what did. This is the distinction I am
trying to make, and that's what I find confusing about the FAQ
entry as it stands now. Do you see my point now?

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.


> As a port maintainer, this means I can produce a port that does
> not accidentally depend on software that MacPorts doesn't know about,

Again, this is not entirely true: the proper way for a port to
not accidently pick up unwanted dependencies is to say --disable-whatever
in the Portfile (and yes, I have run into that problem in ports
I maintain). Not all ports provide a way to declare this, so
you make sure it doesn't happen by removing /usr/local altgether,
or making the user remove his /usr/local, which you will agree is
a pretty extreme measure on a UNIX system.

That's not repeatable build, that's alibism; in fact, it is
exactly what you were (rightfully) arguing against before:
such a build is only repeatable on systems that do look like
the maintainer's system, namely, they do not have anything in /usr/local.

In other words, the thing that makes your build "repeatable"
is that there is nothing around that the port might accidentally
pick up, not that macports is under /opt/local.

Obviously, to be able to do this, you must have macports
somewhere else than /usr/local, because /usr/local might
be at certain ports REQUIRED NOT TO EXIST. This explicit
reason is what I am missing in the FAQ.


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

But the problem is not that the incompatible third party software
is installed IN THAT LOCATION; the problem is that incompatbile
software is found and picked up AT ALL. Having macports in /opt/local
does not solve this; not having the other software around is what does.

> If it's all intermingled, I can't reliably keep it from being found
> and used when building software for MacPorts.

An if it's NOT intermingled (specifically, macports stuff under /opt/local,
other stuff under /usr/local) IT WILL STILL be found and used. Do you 
see my point now?

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

Yes, that will solve it. But only this, what you call absolute worst,
is actually the point that makes the build repeatable, isn't it.

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

Yes - as long as they also do not have /usr/local on their system,
which they most probably do.

> This is what "repeatable build" is about.

No. It would be "repeatable" if it built as fine on a system
that has shit under /usr/local as it does on your system that does not.
That would be repeatable. Requiring the user to make his system
look (temporarily) like yours is not what you could call repeatable.


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

I have been using this mistaken, broken system
for years without problems, thank you.

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

Such as FreeBSD or OpenBSD?


I really don't mean this to be offensive in any way.
I am glad I have macports, and it helps me very much.

I just think that the explanation about /opt/local
and /usr/local in the FAQ is not very clear.

I will try to come up with a better reformulation based
on what people have explained to me here.

At any rate, thank you for your time.

	Jan