/usr /opt split proposal [long]
[this is long, very long, sorry. It also needs a comfortable chair and a
glass of Finlandia vodka near your other hand :-) ]
Proposal to split /opt from /usr
The FHS draft makes a clear separation of the fs hierarchy,
distinguishing from the four orthogonal categories of files:
+---------+-----------------+-------------+
| | shareable | unshareable |
+---------+-----------------+-------------+
|static | /usr | /etc |
| | /opt | /boot |
+---------+-----------------+-------------+
|variable | /var/mail | /var/run |
| | /var/spool/news | /var/lock |
+---------+-----------------+-------------+
where sharable is intended for things that can be shared between
different machines (despite the architecture), and unsharable is
intended for files whose content is absolutely relative to only one
machine, the local one.
Orthogonally it distinguishes between static data (those files that can
reside on a read-only fs), and variable data, that must be read-write.
Then FHS makes a third distinction, saying that /, /usr, /opt, /home and
/var may be put on separate fs (and I think this is a good idea),
because / (root) could be optimally put on a small partition or on a
ram-disk, /usr (and/or /opt) could be a read-only mounted partition, and
/home is a part that could be radically different from host to host, and
/var because it contains highly variable data, part sharable and part
not.
This distinction between three levels has the aim to accomplish the
three tiers of goals of the three parties involved in managing a file
system:
OS producers, local sysadmins and software producers (OS independent).
Each of them as different goals:
1) the OS has a goal to reduce user's namespace pollution keeping
the files separated by their USE by the user: binaries, libraries,
data, etc.
2) The sysadmin has a goal of keeping sharable data separated from
unsharable and read-only separated from variable data.
3) The software producer has the goal to reduce differencies between
the various ports of the program on different OSes, and also to use
his own tools to install, manage and everything, because there
aren't any reliable standard that fits all OS (for these tools).
Thus SW producers prefers to have all their things closed in a
single hierarchy on whose organization they have the last word.
Well, we can see how the division into separate file systems accomplish
the second goal, while their subdivision in directories like bin, lib,
etc. accomplish the first goal.
The third goal is accomplished keeping /usr and /opt separated.
I dare to cite the fhs:
/opt -- Add-on application software packages
|
+-<package> Static package objects
/opt is reserved for the installation of add-on application
software packages.
A package to be installed in /opt shall locate its static files
in a separate /opt/<package> directory tree, where <package> is
a name that describes the software package.
| Programs to be invoked by users shall be located in the
| directory /opt/<package>/bin. If the package includes UNIX
| manual pages, they shall be located in /opt/<package>/man and
| the same substructure as /usr/share/man shall be used.
+---I don't agree with this part, because it violates goal three.
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.
Package files that are variable (change in normal operation)
should be installed in /var/opt. See the section on /var/opt
for more information.
Host-specific configuration files should be installed in
/etc/opt. See the section on /etc for more information.
No other package files should exist outside the /opt, /var/opt,
and /etc/opt hierarchies except for those package files that
must reside in specific locations within the filesystem tree in
order to function properly. For example, device lock files must
be placed in /var/lock and devices must be located in /dev.
BEGIN RATIONALE
The use of /opt for add-on software is a well-established
practice in the UNIX community. The System V Application Binary
Interface [AT&T 1990], based on the System V Interface
Definition (Third Edition), provides for an /opt structure very
similar to the one defined here.
The Intel Binary Compatibility Standard v. 2 (iBCS2) also
provides a similar structure for /opt.
Generally, all data required to support a package on a system
should be present within /opt/<package>, including files
intended to be copied into /etc/opt/<package> and
/var/opt/<package> as well as reserved directories in /opt.
END RATIONALE
Well, here is FHS position. Now we can start discussing things from OUR
point of view, as OS producer.
Talking about our main distribution, we distinguish packages in two
ortogonal ways: Section and Priority.
In the section separation we distinguish packages by content, while in
the priority separation we distinguish packages by their closeness to
the core of the OS.
In fact we have "required", whose package are absolutely necessary to
the OS, "important" for packages expected to be in a Unix system,
"standard" for packages that can stay in a _reasonable_ small character
based system (this description astonishes me, but I can understand its
purposes), and "optional" for all other packages.
In bo/main we have 980 packages: 43 required, 17 important, 60 standard,
750 optional and 110 extra.
This shows me that "optional" should be splitted, and probably "extra"
is misused.
Anyway, basing on this distinction, we should say that the first three
priorities surely are a basic complete core system, which we could call
the OS. Surely there are "optional" packages that are part of the core
OS, and are there only for the supplementar restriction imposed on
"standard" (the reasonable small character based OS). We could also
agree that a part of the "optional" packages belongs to the different
graphic systems we distribute (X11 and svgalib), but that only a part of
them constitute the core part of the grafic system, and the rest are
optional packages.
Well, we could continue this analysis moving farer from the core of the
OS and separating things in basic and optional.
We will come to a list like this:
core
required
important
standard or char-sys-core
basic or char-sys-standard
graphic
X11-core
X11-standard
SVGAlib-core
optional
char-sys-optional
X11-optional
SVGAlib-optional
Well, my idea is that we should put a line separating things belonging
to the OS and things "optional". Purists could put the line just before
the "graphic", while I would put it just before "optional".
This line should separate packages that installs under /usr from those
installing under /opt .
If you think that I have jumped on an unobvious conclusion, please
consider this particular thing: When we talk about a "package", we
always think in terms of .deb packages for debian, .rpm packages for
red-hat, and so on.
This is because we couldn't sit on a common table and decide to create a
common package format and adhere to a common file system scheme, in
spite of the FSSTND. If we did (but we are still in time to do this), we
would have a singular package manager to be used by all the OS
distributors.
Differencies would be in the "core" system while "optional" packages
should work out of the box on EVERY distribution that follows the
standards.
Do you see now where I am going?
"core" packages would be created and distributed by the OS (debian would
have their, Red Hat their, maybe conflicting each other to avoid
problems, while programs intended to be used on _all_ systems, would be
packaged _directly_ from their source.
Thus the core part belongs to the /usr file system, while the "optional"
part belongs to /opt. The fact that "debian" is now considering to
package kde is because the kde group doesn't see any reason (not yet) to
create natively a kde.deb package, but this is only a temporary
workaround. If we would become widely used, that would happen.
I think that, when packaging "optional" programs, we should consider our
work as _belonging_ to the program creators, and we do it only because
we want to let debian's users use that program while the program creator
isn't considering (yet) worth to do so.
This is _very_ important difference, that should be kept in
consideration indipendently from the goal of a common pakaging system,
beeing this dpkg or rpm or upm or what.
CONCLUSIONS (for those skipping all this rationale)
I suggest to wider the separation in the Priority field and use it to
distinguish from stuff belonging to the OS and optional stuff.
I propose to set policy that the "core" part goes in /usr (and the rest,
as we do now) and the "optional" goes to /opt (with a policy better
organized than the one proposed in the FHS draft.
Thanks for your patience,
Fabrizio
--
| fpolacco@icenet.fi fpolacco@debian.org fpolacco@pluto.linux.it
| Pluto Leader - Debian Developer & Happy Debian 1.3.1 User - vi-holic
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E
Reply to: