Re: [kde] setting an /opt precedent
On Thursday 17 January 2002 15:21, Daniel Stone wrote:
> You might note the discussion on debian-kde of late, where Eray is
> attempting to set a precedent by installing KDE3 into /opt/kde3. Let me
> first disclose my viewpoint: I think this idea sucks, as you can clearly
> see from my postings.
>
> My main concern is that we'll set a precedent here in Debian for this
> sort of behaviour. AFAIK no Debian package has ever touched /opt; in
> fact I'm pretty sure it doesn't even exist on a default install.
>
> So, please read the thread and state your opinions. I know it's a KDE
> issue, but I feel it affects Debian as a whole, since putting something
> in /opt ("SuSE and RedHat do it, so it *must* be good!"), would set a
> major precedent for Debian.
There was much argueing with Debian policy and FHS to decide what is
allowed and not. Fortunately there is no need to use them at all to
decide what's good and what's bad or right and wrong.
Just look at the organizaton of the tree used Kby DE, Gnome, X11,
apache or any other of the big software projects. All those projects
do what Debian tries to do with all of them together in a subtree
starting at '/'.
The common view, all apps use, users and admins see,
is the filesystem. That's why the 'subtree' approach sucks.
Everyone sees this loosely coupled stuff lying around
but what he/she really wants is a tidy and well organized
subtree '/'.
Sometimes projects talk to each other, like the window
manager developers and now it's possible to exchange them.
Nothing to do for Debian. Good for Debian and it's users.
Sometimes projects start a discussion, like KDE and Gnome
with the .desktop files. If this ever find an solution,
and other tools support it (also the tools that don't use X11)
Debian can through away it's menu system. Good, less work
for Debian developers. Good for the user.
But in most of the problematic fields of interoperation
projects have not started to find a common solution and
there Debian tries with it's policy and the FHS to do
what the projects don't do. Hard job for Debian
developers. Good for the Debian users.
We know from software that decoupled system are easier to
handle. That's why most distros choose the /opt/<project>
approach. But the Admins and User sooner or later see
the big picture: it's just set of decoupled systems that
play more or less (if at all) well together.
IMO what's needed are better ways to replace/test/rollback
large collections of packages. Then no one will need or
miss the /opt/<project> approach.
Unfortunately I have no solutions for this problem, but I'm
very thankful that so many Debian developers work so hard in
their free time to make the subtree '/' a better place.
Achim
--
To me vi is Zen. To use vi is to practice zen. Every command is
a koan. Profound to the user, unintelligible to the uninitiated.
You discover truth everytime you use it.
-- reddy@lion.austin.ibm.com
Reply to: