>>>>> "Brian" == Brian Dean <[EMAIL PROTECTED]> writes:
Brian> I'm really not exactly sure what you are complaining about.
Brian> For example, the last time I built Emacs for Solaris (several
Brian> years ago admittedly), by default it installed itself into
Brian> /usr/local. If you install Emacs onto FreeBSD, it goes into
Brian> /usr/local. The behaviour is the same. Are you proposing that
Brian> since FreeBSD provides a set of patches so that Emacs builds
Brian> cleanly, that it should therefore install it somewhere other
Brian> than /usr/local?
I'm jumping into the middle of an argument that I havn't been reading,
but I've had the very same argument with a number of people. It's
For foreign or not-so-foreign packages and software, I've seen
/usr/local, /local, /usr/contrib, /opt and /usr/pkg. One site that I
worked at was even pedantic that /usr/contrib was for externally
generated software and /usr/local was for software written and/or
maintained locally. I've also worked in environments where different
directory structures implied the level that the IS guys intended to
support the software.
Arguing about any of that in an OSS project is silly. However,
I believe that /usr/ports should install all it's software in one
place and that place _shouldn't_ be /usr/local. Reasoning:
- having it install in /usr/X11R6 and /usr/local is confusing. Having
random software put itself in either /usr/X11R6 or /usr/local is
more confusing. Having ports even migrate from /usr/local to
/usr/X11R6 is even more confusing.
- having all ports under one tree allows you to share a tree of ports
without sharing a tree of /usr.
- would allow package management (eventually) to say that every file
under /blah is accounted for by the package database.
- (and the reason it shouldn't be /usr/local) ... many packages on the
net install in /usr/local by default ... so I can see the lazyness
in just accepting that. However, /usr/local is a useful place for
an administrator to put things that are not part of the ports
collection that he has hand compiled onto the machine. In many
cases an inordinate amount of work would be required to change a
piece of software that was only to be installed on one machine. It
also forces all ports to be PREFIX enabled ... which is useful.
Now... I think it would be useful to have arguments about more complex
package software that allowed /usr/pkg/foo to hold all of foo and
linking /usr/pkg/bin/foo to /usr/pkg/foo/bin/foo ... 'n stuff like
that. Complete separation and versioning are desireable things. I
suppose if everything was dead accurate (which it's not) you could
account for every file in the namespace ... which would be way-cool
... but separating packages might be more sensible.
... but /usr/pkg supplanting /usr/local is one of the things that I
like about NetBSD.
|David Gilbert, Velocet Communications. | Two things can only be |
|Mail: [EMAIL PROTECTED] | equal if and only if they |
|http://www.velocet.net/~dgilbert | are precisely opposite. |
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message