Joe Kelsey <[EMAIL PROTECTED]> types:
> Mike Meyer writes:
> > Sure, the software in ports/packages aren't part of FreeBSD. Using
> > that to claim they should have the same status or treatment as locally
> > written or maintained software is a rationalization.
> You are simply wrong in your characterization of /usr/local. As far
> back as I can remember, /usr/local has been used for locally installed
> software as separate from the default software in /bin and /usr/bin. I
> have personally use /usr/local to install software obtained from Usenet
> since at least 1983. I estimate that 90% of my /usr/local use has been
> for software obtained over some network distribution mechanism, and only
> 10% has been for actually locally written software.
Actually, my characterization of /usr/local agrees with that
100%. What you've missed is that the important characteristic of
ports/packages isn't that they are "software obtained over some
network distribution mechanism." After all, the entire FreeBSD
distribution fits that category. Are you therefore going to argue that
it should all be installed in /usr/local because I get it from a CVS
> Each vendor supplied their own packaging commands, as SunOS did long
> before Solaris (really SYSVR4). The correspondence between ports and
> packages in FreeBSD is really quite separate from the distribution
> packages. Simply because a package exists does not make it part of the
> distribution. At least FreeBSD uses a different nomenclature for each,
> unlike Red Hat which calls everything an RPM and you can't tell the
> difference between what Red Hat officially includes in the system and
> what is simply a pre-compiled port.
True - mere existence doesn't make a package part of a
distribution. Being put on the distribution media makes it part of a
distrbution. However, as shown above, the distribution mechanism is
*irrelevant* to this debate.
> distribution: officially part of FreeBSD.
I don't agree. A distribution is a software collection bundled and
> port: A set of patches, source and makefiles to ease the process of
> installing third part software.
Yes, and the ports are part of the FreeBSD distribution, even if they
aren't part of FreeBSD.
> package: A pre-compiled port.
Yup. Some some packages are part of the FreeBSD distribution (again,
without being part of FreeBSD), and some aren't.
> I don't have any problem seeing the distinction between a port/package
> and the official FreeBSD distributions.
Neither do I. Nor do I have any problem seeing that it's *irrelevant*
to the issue at hand. Using the fact that something distributed with
FreeBSD is a port instead of "officially part of FreeBSD" is just a
rationalization for the system defaulting to a behavior that creates
administration problems and increases the overhead of running a
> Joe Kelsey writes:
> > When the BSD started, they tried to distinguish between /usr/local and
> > /usr/public, but that never took hold. Certainly, when GNU
> > distributions started, the FSF very quickly took up the then default
> > (from the long history of standardized distributions in the moderated
> > unix source newsgroups, both before and after the great renaming) usage
> > of /usr/local as the place for network distributed software packages.
> Basically, /usr/local is for anything the local administration wants to
> officially support. The ports use of this (and by extension,
> pre-compiled ports (packages)) is thus completely justified.
Are you therefore claiming that the "official FreeBSD" distribution is
not officially supported by the local administration? Seems a strange
position to take for someone who wants to run FreeBSD.
Of course, anyone who actually deals with users knows that they assume
anything installed on the system is officially supported by the local
administration - even if there are explicit statements otherwise. The
issue isn't support, the issue is maintenance. Anything you get from
FreeBSD - whether officially part of FreeBSD or just a port or package
- will work on FreeBSD as is (failure to do so is a bug), can be
gotten from FreeBSD again, and there are tools bundled with FreeBSD to
detect updates (which come from FreeBSD), install and uninstall the
software. None of that is true for third party software, meaning you
need locally grown mechanisms to back up, install, uninstall,
etc. such software. It's a *lot* easier to do that if the two classes
of software are in two different trees.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message