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

Re: [kde] setting an /opt precedent



On Thu, 2002-01-17 at 16:22, Jim Gettys wrote:
> I'm watching this with more than a little bemusement, being new
> to debian.

Welcome!  Glad to see such a luminary hanging out. :-)

> 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.

We do have ways of migrating between platforms like this.  If you're
interested, check out the very recent archives of the debian-gtk-gnome
mailing list; they're in the process of going through those steps for
GNOME 2.

> 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.

First off, I don't think we're complaining about the KDE project's
choice of default install directory.  Rather, we're trying to decide
where is the best place for *our* KDE packages to go.  KDE is probably
right to allow /opt/kde[23] for their purposes.  But that doesn't mean
that Debian needs to follow them in this regard; indeed, part of the
argument against Debian using /opt is to allow bleeding-edge KDE people
to use /opt/kde without fear.

Ultimately, I think what you're seeing here is an example of a pet
theory getting shot down, and the pet's owner refusing to accept the
death.  We've done some pretty serious migrations before without
resorting to /opt.  I won't claim our method is the best, but it's
worked before (for some value of "worked").




Reply to: