Forrest Aldrich <[EMAIL PROTECTED]> types:
> Haha... okay, then what's the argument about.
> > You're about six years late. The ports system has used $PREFIX for
> > precisely this purpose since October 1994.
As Jacques pointed out, you set LOCALBASE in /etc/make.conf.
The problem is that *it doesn't work*. Well, not very well. Part of it
is that it's only given lip service: the porters handbook says "make
your ports PREFIX clean"; portlint doesn't do any checking about it.
The porters handbook doesn't even provide instructions on how to test
for whether or not a port is PREFIX clean. Making things LOCALBASE
clean isn't even suggested. Admittedly, most port maintainers respond
well when I report that things are broken, but checking for this
should be done before the port is commited, not afterwards!
Lots of other random things break:
Packages built with a PREFIX value cannot reliably be installed with
another value of PREFIX (no, I don't think that should be a
requirement). This means that the prebuilt packages on the CDROM are
unusable under these conditions. Since distfiles have been banished
from the distribution, the pain of setting PREFIX to anything other
than /usr/local for my clients that don't have good network
connectivity is higher than the cost of doing intermixing the two
different file types. For commercial packages, that's not even an
The system perl build checks the /usr/local tree for modules, not the
LOCALBASE tree. Perls module installation package also installs things
in /usr/local, no matter what LOCALBASE is set to. This means that all
ports that install PERL modules either 1) aren't PREFIX clean or 2)
don't find those modules if they are.
The python port breaks the other way: the binary only checks the
LOCALBASE heirarchy for modules(*). Locally maintained modules wind up
being scattered in among the ports modules, and thus require special
treatment. I'm not sure about other ports that support modules, but it
wouldn't surprise me if they had similar problems.
Ports that have build dependencies on other binaries sometimes assume
that the binary in question is on roots path. The startup scripts in
/root set the path to include things in the /usr/local heirarchy,
*not* the LOCALBASE heirarchy. Thus those builds - while being PREFIX
clean - are still broken (not LOCALBASE clean).
In fact, all the hook for supporting "local" things are pointed directly at
/usr/local; none of them check LOCALBASE.
All of these would be solved if the FreeBSD took a lesson from their
peers. Most of them could be solved without changing the default value
for LOCALBASE - if people wanted them solved.
*) Python calls them packages; I'm using the Perl terminology to avoid
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message