Subject: Re: /opt (NOT!)

From: [email-masked] (David Champion)

> 1.) Optional packages should not be cluttered all over /usr/local, but be
> placed
> into single directories and making files of public interrest available by
>     using links to some well-known directories (e.g. /usr/local/bin).

I co-operate a site with 22 stations running 4 operating systems on 7
architectures, each employing AFS, NFS, and local application
installations.  I'll spare you my many gripes about assumed bases of
installation, etc., but let me point out that for anything more than
very localized and personal configurations, this model is quite
useful.  Consider the following:

	- You install a package.  It works well, but a year later you
have to replace it with the next release.  Now you have to locate all
the components of this package and back them off to warm storage in
case the new version doesn't work, then install the new set in place
so that users don't have to go reconfiguring everything to use the new
release.

	- You install a package, try it out for a week, and finally
notice that it's corrupting data.  You have to get rid of it before it
causes any more trouble.  Now you have to locate all the components so
that none of it can be run; any single part of the package can be the
culprit itself, or interfere with a patch or retrograde you put in
place of the broken installation.

	- (I'm sure anyone could come up with more examples.)

I think it's essential to have an installation model that at least
allows for encapsulation of packages.  I typically create a single
directory for each package I intend to install (OK, actually it's an
AFS volume, but it looks like a directory), with whatever logical
organization is needed: /.../foo/lib, /.../foo/bin, etc.  When it's
time to remove this package, I simply install the new one into a new
directory, rename the old one to something else, and rename the new
one to look like the old one.

Since we also have 3000 users at this site, we symlink executables and
libraries into "standard" paths.  Support files need not be linked,
since their paths are either hardcoded (not if I can help it) or
specified in a config file.  The symlinks don't even need to be
modified for most upgrades, and finding them when a package is totally
removed is pretty trivial -- anything linking into /foo/bar/coolapp is
quite plainly a target.  For a lot of the software we run, it would be
impossible to determine exactly what to rm without consulting a lot of
manuals, or keeping very accurate logs of every file (or sometimes
directory) on the disk.  And system upgrades are so much easier.

So... that's background for why I agree with the general suggestion.
I know a lot of you didn't need to hear all the reasoning, but some
might have.

>> 2.) I don't really care if all those packages are placed below /opt or
>>     /usr/local. I just suggested /opt as a sign for the new scheme.

I think it does matter.  If NetBSD-Amiga were a completely new Unix,
I'd say "Who cares?"  But there are no more completely new Unices, and
NetBSD-Amiga wouldn't be one if there were.  It's important to stick
with whatever tradition you come from until the whole tradition can be
safely uprooted and replaced with SVR4 :-)  This point has been made
already, but for a project like an Amiga -PORT- of NetBSD, it's
crucial to keep things fairly standard, so I don't mind repeating it.

If someone were to propose having all of NetBSD adopt /opt, that would
be fine with me.  I'd like to point out, though, that the requirements
of such a model should be well documented.  (My first encounter with
/opt was in installing Solaris 2 -- my previous SVR4 experience was in
hybrid systems.  Sun suggested making /opt a partition mountpoint,
and said that 16M was fine.  My first installation that wanted /opt
required that I abandon the partition and install in /usr, with a
symlink from /opt.  Typical SMI.)

Note that if "standard" but optional material installs to a
partitioned model like Hubert's, the build source should reflect this.
Is NetBSD as a whole ready for such a change?  This seems to me to be
an issue for a larger body than the Amiga installation developers.

I hate to hold back this kind of foresight, but I do think it's a
bigger matter than how to write NetBSD-Amiga install scripts.

There... this should make up for my silence to date.