On Thu, 2002-01-17 at 02:55, Jarno Elonen wrote:
> It's that they grow /usr/bin quite a lot faster than any "conventional" unix
> tools and make it very hard to have multiple versions of the desktop on a
> same computer.
If the upstream authors don't (or can't) make it so multiple versions
can be seamlessly installed side-by-side, then we (Debian) will simply
pick a version and use it.
Here is my biggest problem with your proposal: How do you define KDE or
GNOME? I don't personally use KDE, so let's take an instructive example
from GNOME: ORBit, the CORBA ORB implementation used in GNOME. Should
this go in the theoretical /opt/gnome or whatever? Is it "part of"
GNOME? Yes, but it is perfectly legitimate for non-GUI apps to use
ORBit, or even for KDE apps to use it!
So you see, the problem with your proposal is the fact that the division
lines would have to be more-or-less arbitrary. In fact, it would make
much more sense to me to take your proposal to the logical extreme, and
somehow give every package its own directory, like GNU Stow does. Then
we could maybe have an intelligent way of populating /usr/bin with
symlinks or something, and put it under admin control. But we don't
currently have the techonology to do this, so until then, we should
stick with the current Debian policy, and not make arbitrary exceptions.
One other thing to consider is that while we might consider GNOME or KDE
"large" now, if the rate of free software growth continues to increase
at the current rate, then we will have much larger projects to deal with
in the future that make GNOME or KDE look small. This means our
decision to use /opt/{kde,gnome} will no longer be justified.
