Interpreting FHS
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 16 January 2002 13:24, Daniel Stone wrote:
>
> I will not, under any circumstances, touch /opt. I believe Debian policy
> prohibits it anyway.
I read the complete section for opt in the FHS. Here is my analysis.
Using /opt for packages doesn't violate the policy in any way. I repeat,
James *is* right. I suggest you to read it thoroughly before making further
judgement.
/opt is not intended solely for non-free add-on packages.
It is provided for add-on packages of any sort.
Here is the description
/opt -- Add-on application software packages
+-<package> Static package objects
/opt is reserved for the installation of add-on application software
packages.
It turns out that add-on does not mean "third party commercial vendor
supplied" in the following text of FHS. So indeed whoever interpreted it for
Debian (somebody who is seriously unable to comprehend English) interpreted
it incorrectly beforehand. It means what it says: "application packages" that
can be installed/removed. Much like applications in debian. (which are not
"system" software like libc)
Here is a part that does interest debian:
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 those subdirs: /opt/bin, /opt/doc, /opt/include, /opt/infor, /opt/lib,
/opt/man are forbidden. Don't touch those. You may do anything else you want
with /opt in the manner described in detail in section 3.8
And the following excerpt I think clarifies the situation once and for all.
Distributions may install software in /opt, but should not modify or
delete software installed by the local system administrator without the
assent of the local system administrator.
: This means that Debian can install software in /opt except those subdirs
listed above. Period.
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.
: So this is not something invented by Red Hat or SuSe.
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.
: Most large application software packages are structured that way.
The minor restrictions on distributions using /opt are necessary
because conflicts are possible between distribution-installed and
locally-installed software, especially in the case of fixed pathnames
found in some binary software.
END RATIONALE
: The restrictions on subdirs of /opt are justified here.
As I said, there is absolutely nothing in the FHS or Debian Policy that
prohibits installing KDE in /opt. We need to interpret FHS correctly. KDE is
an application package (a rather big one, though) and it would not be
incorrect to install it in /opt as it is commonly done. Whoever thought
policy did prohibit it must have interpreted FHS in a failing way; I assume
they thought "add on" necessarily meant "third party commercial vendor
supplied" whereas it does *not*. See the excerpt above to see what it says
about distributions like red hat or debian.
Thanks,
- --
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8RYvMfAeuFodNU5wRAtXJAJ9y5MCpuEf4ZnmG+p9yqnV4b4hfqACdG0kI
92JzhUkBh0zm7ZN+rSsnTWs=
=LcSJ
-----END PGP SIGNATURE-----
Reply to: