Re: [kde] setting an /opt precedent

[jg@pa.dec.com (Jim Gettys)]

I'm watching this with more than a little bemusement, being new
to debian.

I think *the real point is being entirely missed*.

In large software systems, particularly young ones like KDE, Gnome, and 
some others, there comes a point of the terrible flag days when you have 
to move from one platform to another, which are not necessarily upward 
and more importantly, not downward compatible.

The project has to be able to have more than one environment installed
simultaneously, both for development, and for users, *SINCE IT JUST ISN'T
POSSIBLE TO GET ALL APPLICATIONS MOVED SIMULTANEOUSLY*.  The scale
of these projects is such there is no other way forward, but to enable
both versions to be used side by side, possibly simultaneously.

KDE has this problem today with KDE3, and Gnome is beginning to face it with
Gnome2.

So somehow, some way, you need to be able to have more than one
version of the applications available so that users can choose
how much they are going to bleed (and similarly, libraries, header
files, etc).

This, for example is why there is /usr/X11R6, (and before
that, previous versions back to X11R2); people could choose
what to have in their path, and the right thing would happen, and
the migrations proceed, both for users and developers.

And yes, projects can and should mitigate this; sometimes it is feasible
to have multiple versions of headers and libraries side by side, and sometimes
not.

So, if you don't like /opt, then make a concrete suggestion to KDE
(and something similar may need to happen for Gnome) about where to
put things, rather than whining about FHS and the proper uses of /opt.

Because you aren't going to be able to make everything happen
all at once, no matter how much you want them to.
				- Jim Gettys

---
Jim Gettys
Cambridge Research Laboratory
Compaq Computer Corporation
jg@pa.dec.com