Re: [kde] setting an /opt precedent
-----BEGIN PGP SIGNED MESSAGE-----
On Thursday 17 January 2002 18:49, Junichi Uekawa wrote:
> If you are talking about random add-on packages that
> is distributed from kde.org or whatever else,
> that would be fine, as long as it is independent from Debian.
> We, as Debian, do not use /opt.
> We reserve it for third party software.
> There might be a third party software which may want to install in
> We allow that to happen.
> Please read and understand the policy, and why we have a good
> reputation on not having touched /usr/local.
/usr/local and /opt are quite distinct. I appreciate your good intention in
presenting your point of view. However, unfortunately, your above statement
assumes that policy prohibits use of /opt while it does not, that is it does
not explain at all how, why, or where it is prohibited. It is the same
answer saying that "/opt violates policy" I heard from many. [+]
Prior to saying that, you should have read the relevant section in policy,
seeing that it simply delegates all responsibility to FHS, read the relevant
section 3.8 in FHS and conceived why I said debian packages may install files
in /opt/<package>. I also refer you to the thread titled "KDE Filesystem
Structure", and messages in debian-kde explaining the situation:
There is absolutely *no* mention of /opt being reserved for third party
vendors [!]. The FHS standard is written in a very plain language, and it
explicitly says what is allowed and what is not allowed for distributions.
I'm having to restate myself; it shouldn't be this difficult to read a
section of a standard. The catch is that /usr/local is for local system
administrator's use. Debian cannot install any files there. /opt is
different. Let me repeat it. /opt is not the same thing as /usr/local. I will
also have to restate that "add-on does not mean third party" as the FHS
itself clarifies such a misunderstanding by explicitly and without doubt
saying that distributions *can* install files in /opt/<package>, however
there are certain justified restrictions on using /opt. A set of subdirs of
/opt, not /opt itself for those who are too lazy to read the standard itself,
namely "/opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man
are reserved for local system administrator use". All components of a
software package, on the other hand, should be installed in /opt/<package>
directory tree. [*]
There are also other rules such as the configuration of a package maintained
I'm hoping I have made it clear this time. Judging from the responses, it was
needed. Before saying anything else, I recommend those interested to *read*
that section of FHS in complete, and all other relevant sections, and then
state your opinions.
I have merely presented the facts. Of course, if you think FHS is badly
designed in this respect you should be offering an improvement to FHS which
should be directed to the fhs mailing list. AFAICT, removing /opt from the
standard would not be an acceptable patch, however you may have thought of an
improvement over the existing scheme.
[+] The other typical response that "Well it may not violate the policy, but
it does not seem to be consistent with other packages." is a much more valid
[!] It is so only in your minds.
[*] They leave the definition of a "package" to the implementor, as physical
packages do not always correspond to the logical package. For instance in
debian, many software packages are split into subpackages.
Eray Ozkural (exa) <email@example.com>
Comp. Sci. Dept., Bilkent University, Ankara
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
-----END PGP SIGNATURE-----