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

Re: [kde] setting an /opt precedent

On Thu, 2002-01-17 at 17:13, Jim Gettys wrote:
> My point is that often, in these large systems, you need both
> systems in parallel, simultaneously, both for developers and users.

Right.  That's what I was referring to in regards to the work going on
in debian-gtk-gnome.

> You can't just say: "we'll only have one version of nautilus installed
> at once", for example; people, particularly on shared systems will need
> both versions available simultaneously.
> With advance planning, such projects can mitigate, but not eliminate
> these problems.  Shared libraries have both helped and hurt
> this situation....

*Debian* can say that, in our official release.  For example, I think
it's a foregone conclusion that woody will ship with GNOME 1.4 and KDE
2.  Any support we happen to provide for GNOME 2 or KDE 3 will be
incidental (accidental?).

There have been cases where we have explicitly supported multiple
versions of large systems; see, for example, the Perl support in
potato.  (And Perl is central to much of Debian's core infrastructure,
too, which complicates things; you can't install a Debian system without

Sysadmins, of course, are free to override us by installing from source
to /usr/local or /opt, and developers can always track unstable, which
usually has one or two migration projects of this type going on at any
one time (freezes excepted).

> And I think Debian owes the KDE packaging folks some guidance on
> if not /opt, then where....

Well, maybe.  Again, we don't mind KDE installing to /opt from source,
or even from their own debs that they distribute.  It's our packages
that we're concerned about.  As long as you can do "./configure
--prefix=/usr" or some such, we don't really care where they prefer to

And if they can't do anything like "./configure --prefix=/usr", maybe we
can help give them that.

Reply to: