Re: [kde] setting an /opt precedent
On Thu, 2002-01-17 at 10:34, Eray Ozkural (exa) wrote:
> On Thursday 17 January 2002 17:22, Daniel Stone wrote:
> > /opt is for "add-on" software. kde is not an "add-on". we package it as
> > part of the distribution, it's not added on.
>
> That is a wrong reading of standard text.
>
> /opt -- Add-on application software packages
>
> There is a difference between system and application software. C++ library is
> system software, while a desktop environment like KDE is application
> software. System can continue functioning in the absence of such application
> software that is optional, hence the expression "Add-on".
By your logic, the phrase "add-on" therefore is a no-op.
Standards are generally written such that all words add meaning, and
interpretations that strip meaning from words or phrases are generally
considered to be wrong unless there is no consistent way of interpreting
them otherwise.
In other words, the standard grammatically uses "add-on" as a modifier
to "application software packages". We must therefore assume that the
word does, in fact, modify the phrase. Since your interpretation causes
no modifications, other interpretations must be preferred.
Stated yet another way: My system functions fine without vi. Should we
move all the vi clones to /opt/vim, /opt/nvi, /opt/elvis, etc.? Do we
then install a symlink via alternatives for the "preferred" vi to
/opt/vi, with /opt/vi/bin/vi the path to the preferred vi? All of this
would be perfectly fine according to your interpretation of the FHS, yet
it would destroy the spirit and purpose of the FHS: to provide a
standard way for the system to lay itself out so users and third-party
developers know what to expect. The reason: no one seriously would call
vi an "add-on", even if it is an application software package. So,
there must be a distinction between "add-on application software
packages" and "other application software packages" (a distinction you
deny).
The final question to ask, then, is only whether we consider KDE to be
an "add-on". We don't; it's in main, which is the only test the project
accepts for some software to be "part of Debian". (Put another way: if
KDE is "just an add-on", then what was all the fuss about back before Qt
went GPL?) Therefore, KDE does not belong in /opt. QED.
> As stated in section 3.8, distributions can install software in /opt in
> accordance with FHS.
>
> Moreover, this is an established practice as emphasized in FHS standard text.
Deliberate blockages are placed in the way of the distribution vendor by
the standard, however. The restrictions on /opt/bin and so on imply
that a package installed in /opt must be manually enabled by the
sysadmin before it can be used. Is this what we want to do to poor KDE?
Think again about /opt/vi. Most users would expect "apt-get install vim
&& vi foo" to work. But we can't add vi to /opt/bin, and we can't
change the PATH of the parent shell to include /opt/vi/bin. So you have
to log out of the shell you're in before you can use vi, or type
"/opt/vi/bin/vi foo"? What if you ran the aforementioned command in a
single-user shell, and couldn't exit without causing the system to go
multi-user? And all of this is supposed to be an improvement?
The implication is that, although distros are allowed to install into
/opt, it is discouraged; it should only be done if really necessary. I
have heard lots of reasons why it might or might not be allowable to
install KDE into /opt, but no reasons why it might be necessary.
Reply to: