[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [kde] setting an /opt precedent

Hash: SHA1

Hi Junichi,

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.

Well. No.

> There might be a third party software which may want to install in
> /opt/kde
> 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 
in /etc/opt/<package>.

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) <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
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org


Reply to: