Re: Installation-issues

[Nicholas Lee <N.J.Lee@statslab.cam.ac.uk>]

On Fri, 11 Dec 1998, Jan Ekholm wrote:

> On Fri, 11 Dec 1998, Adrian Ratnapala wrote:
>
> >yOn Wed, 9 Dec 1998, Christian Reiniger wrote:
> >
> >> Uh, I don't like the idea of /opt/bin etc. After all that's what /usr/local
> >> is for IIRC...
> >
> >Exactly.
>
> Well, according to 'Linux File Hierarchy Standard' /opt can be used for
> custom packages. Do a search on AltaVista with the keywords '+FHS +linux'
> and you'll fins it. The old FSSTND did not metntion /opt AFAIK, but this
> new one does. I think this means that /usr/local is reserved for stuff
> that's crafted at the local site, and not in common use, while /opt can be
> used for selfcontained packages. But this does really not matter at all.


http://www.pathname.com/fhs/
http://balug.org/meetings/may1998/quinlan15.html mentions something about
/opt being for:

"" For add-on application software packages that need a "playground"  ""

>From http://www.pathname.com/fhs/2.0/fhs-3.8.html:

""The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib,
and /opt/man are reserved for local system administrator use. Packages may
provide "front-end" files intended to be placed in (by linking or copying)
these reserved directories by the local system administrator, but shall
function normally in the absence of these reserved directories.""


So this might mean that a library (eg zombie) package shouldn't be
installed in /opt/zombie, unless you consider it an application.

Looking at /usr/lib, http://www.pathname.com/fhs/2.0/fhs-4.5.html:

""/usr/lib includes object files, libraries, and internal binaries that
are not intended to be executed directly by users or shell scripts.

Applications may use a single subdirectory under /usr/lib. If an
application uses a subdirectory, all architecture-dependent data
exclusively used by the application should be placed within that
subdirectory. For example, the perl5 subdirectory for Perl 5 modules and
libraries. ""

So /usr/lib/zombie might be a possibility.

Since http://www.pathname.com/fhs/2.0/fhs-4.6.html explicitly mentions
/usr/local/games for local game binaries, it might still be worth
considering /usr/local.


> >> Yep, but don't rely only on rpm. Some people (like me) prefer to
install > >> (almost) everything from source and thus have to remove the
stuff by hand.  > >> Deleting a dir in /opt and after that the stale
symlinks in /usr/local/* is > >> easy.  > >> > >Besides if you use rpm
properly, you can just install straign > >to /usr (in fact you should).
You only need to worry about > >"hand made" installs.  > > Yep, in order
to build an RPM I still have to have a normal 'make install' > in my
sources that work ok. 'rpm' just picks the files from all around the >
filesystem into the foo.rpm -file after 'make install' has benn executed.
> This means that if I have a working bin/src-RPM then I also have a
working > tar.gz. I plan on using all three of them.



Possibly there is room for us to develop some sort of meta installation
process, to easy the creation of packaging for the games developers.   ie,
give some sort of meta information, a developer could go make rpm or make
deb and "hey magic!" there it is.


> All RPM:s (almost) seem to use /usr, /etc for all stuff, or generally
> dropping stuff over /, instead of using /usr/local or /opt.

Using /usr all the time becomes very messy, and is something I dislike.  I
prefer to keep each package as objectised as possible with in the
filesystem, to easy maintance.

Of course we should consider the FHS in consideration of installation
policy.

Nicholas


--
      "I reserve the right to contradict myself"
Nicholas Lee (Li Peng Ming)  n.j.lee at statslab.cam.ac in uk
Somewhere Out There