Andrew Reilly <[EMAIL PROTECTED]> types:
> On Sun, Dec 10, 2000 at 12:31:10PM -0600, Mike Meyer wrote:
> > 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.
> So do you also put the configurations in ${PREFIX}/etc, or
> /usr/local/etc? Even though you got them from a readily
> replaceable source, you can't retrieve your local configurations
> that way.
${PREFIX}/etc, and stored in perforce. The perforce database is on
/usr/local, and saved along with everything else.
In fact, *all* my system configuration files are stored in
perforce. In theory, I can restore a system configuration from
that. Since I haven't actually used it, I expect it to work as well as
setting LOCALBASE works.
> > 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
> > discussion.
> Well, I'll just stick my oar in for /usr/local. I count myself
> among the aesthetically dismayed when I first encountered /opt
> on a SunOS box. (Or was that Solaris? Time fades...)
I dislike /opt as well. For two reasons. One is that it's not on /usr
meaning I have to either set aside another large FS for system
software, or tweak things to get it there. The other is that all the
packages have their copy of the hierarchy. If there were a hook to
install symlinks in a standard heirarchy under /opt, it wouldn't
bother me so much. But there isn't, so I have to figure out what needs
to be installed, do it by hand, and take some action to insure it gets
recreated if I need to do that.
> > 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.
> Don't you keep the source that you write somewhere in your home
> directory? I do.
Yup. I also keep the source for random software from the network in my
home directory. I don't keep the source for ports anywhere. That's
part of the basis for the claim that "installed over the network" and
"FreeBSD packages" are *not* identical, and losing the ability to
easily separate them is bad.
> > 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.
> Whenever I have to build something outside the ports hierarchy,
> I finish by diffing the orig and modified source trees. I put
> the source tarball into /usr/ports/distfiles, in case someone at
> FreeBSD gets around to building a port of it, and stick the
> diffs in my $HOME/src directory.
Why don't you go ahead and turn it into a port, and submit that? I've
done that - even for locally written software. Being able to use the
ports mechanisms to maintain the installation of software is a win. I
also PR them, and every once in a while one of them gets committed
before the ports structure changes so much the port is outdated.
Whether I turn true third party software into a port or not, I put
network sources in an external source branch, and my build version in
a local branch so I can use source software management tools to deal
with upgrades from the vendor. I *never* do that with a port. I don't
manage that software - someone appointed by FreeBSD does. Again,
that's a reason for wanting the two kinds of software in different
hierarchies, and FreeBSD coopting the place where much of that
software expects to be installed being a pain.
> > 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).
> I agree that PREFIX/LOCALBASE should work: you can't legislate
> taste. I'm going to keep it to /usr/local and /usr/X11R6,
> though, thanks all the same.
Making the default something other than /usr/local makes it more
likely that PREFIX/LOCALBASE will work. Also, as was pointed out
elsewhere in the thread, if ports go somewhere that nobody uses for
anything, a simple symlink will make it look like it's where ever you
want it, and you get the two things merged. If the default occupies
something you want for some other use, the cost of moving it is very
high (i.e. - 3/4ths of a subscription is packages that will install in
the wrong place, commercial software packages installs in the wrong
place, having to fix broken ports, not being able to use Perl modules
from ports, etc).
<mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
