Nat Lanza <[EMAIL PROTECTED]> types:
> Mike Meyer <[EMAIL PROTECTED]> writes:
> > Whether or not it's part of FreeBSD is immaterial. It's part of the
> > distribution that comes from FreeBSD, and is treated differentlyh from
> > locally installed software (whether written locally or by a third
> > party) in every case *except* where it installs - and that's only
> > because it's installed in the wrong place.
> > In other words, "It's not part of FreeBSD" is a rationalization.
> Your argument doesn't make much sense to me.
Ok, let's walk through the details (bottom of the letter).
> So if I compile sawfish myself I should install it in /usr/local, but if
> I install a FreeBSD package for it, it should never go in /usr/local?
It should go where you want it to. /usr/local is a bad place because
of it's tradition of being for locally maintained software.
> If I grab a sawfish FreeBSD package from the sawfish website, where
> should that install? /usr/local? /opt? /usr/pkg?
Not /usr/local - that's for locally maintained software. I'd rather it
go on /usr, so I don't like /opt. When I got to choose, I chose
/usr/opt. But anything other than /usr/local on /usr would do as well.
> Third party software is third party software, no matter who compiled
> and packaged it.
That's true. But if it's packaged, it belongs in an area reserved for
*packages*. FreeBSD is the only system I know of that coopts
/usr/local for packages, instead of reserving it for things that are
locally maintained. Whether that locally maintained software is
written locally or comes from a third party is irrelevant to this
> If I install a package of third-party software, the end result should
> be about the same as if I compiled and installed it by hand -- the
> packaged software is a convenience, not a fundamentally different
That's correct. The differences aren't in the software, they are in
the administrative regimen. Let's look at how you deal with FreeBSD
proper, ports/packages, 3rd party software that isn't from a port or
package, and locally written software.
Administrative FreeBSD port/pkg 3rd party local
Binary from FreeBSD FreeBSD author author
Source from FreeBSD patches and author author
Responsible for FreeBSD Port local local
it building on maintainer maintainer maintainer maint-
my FreeBSD box ainer
requires local src No No Yes Yes
Updates from FreeBSD FreeBSD author author
Patches best sent FreeBSD Port author author
to maintainer maintainer
As you can see, the only difference between locally written software
and third party software is that the author in the latter case is
local. Meanwhile, the primary difference between software that is
part of FreeBSD and a port/pkg is that the person who takes
responsibility for some part of FreeBSD is always a FreeBSD committer,
whereas the person who takes that responsibility for a port/package
may not be a FreeBSD committer. Sure, sometimes that person for a port
is the author - but that's also true for FreeBSD. For 3rd party and
local software, you always deal with the author; for FreeBSD and a
port or package, you deal with an intermediary that has taken
responsibility for the software on FreeBSD, who may *not* be the
The critical difference is the "requires local src configuration"
line. For FreeBSD or any of the ports or packages, I can blow away the
source tree without worrying about needing it back; I can always get
it back from FreeBSD again. For the same reason, I don't worry much
about the binaries. For locally written software, if I lose ths
source, I'm SOL. For true third party software, how screwed I am
depends on how hard it was getting the thing to build on FreeBSD. As a
general rule, I always save them. The binaries get the same
treatment. Having to figure out which is which is *much* easier if the
two are in different directory hierarchies.
Clearly, a package is *not* the same as either third party or locally
written software. For people who don't care about any of those
differences, packages co-opting /usr/local doesn't matter. For people
who do, there's PREFIX - except it doesn't work very well, and can't
work for binary builds (and with the CDROM set no longer having
distfiles on it, that's a major PITA).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message