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

Re: Interpreting FHS



Am Mittwoch, 16. Januar 2002 15:18 schrieb Eray Ozkural (exa):
> 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.

But kde in /opt is sick. You cannot say:
this app is an KDE2 app, so install it in /opt/kde2

This way, you do not look at packages which are somewhat KDE2 but not 
completely (e.g. licq).
Then you probably say: it is only for main KDE. Well that does not make sense 
either.

In my understanding: /opt is for packages that do not fit into the unix file 
system structure with the defined dirs like bin, lib, etc.
What you now want to do with /opt is to make it to something like C:\programs 
on Windows systems.

Does it make sense to have a unix structure defined when you do not want to 
integrate packages into it. If KDE cannot handle this then KDE has a serious 
problem there.

You analyse FHS here what is not prohibited. But does it make sense to do it 
this way? No, because then _every_ package could do it this way (first KDE, 
the Gnome, then whatelse, where do _you_ draw the line?).

HS



Reply to: