Re: [kde] setting an /opt precedent
> Sender: srivasta@golden-gryphon.com
> From: Manoj Srivastava <srivasta@debian.org>
> Resent-From: debian-devel@lists.debian.org
> Date: Fri, 18 Jan 2002 12:26:23 -0600
> To: debian-devel@lists.debian.org
> Subject: Re: [kde] setting an /opt precedent
> -----
> >>"Jim" == Jim Gettys <jg@pa.dec.com> writes:
>
> Jim> The X protocol has remained strictly compatible since X11 shipped
> Jim> in ***1988***!
>
> Cool.
>
> Jim> What did not maintain compatibility were some of the toolkit libraries
> Jim> built on top.
>
> Jim> So you could/can always run binaries, and everything would/does work.
> Jim> Turn on that antique Sun or Microvax in the corner and try it: it really
> Jim> is compatible.
>
> Jim> The issue is how to get all applications updated to new versions
> Jim> of those libraries; there were times when it was not just a
> Jim> recompile.
>
> So why would keeping older shared libs around until they are
> no longer needed not a solution for this issue?
Yes, shared libraries often help. But that is only one aspect of the
problem, maybe the easiest.
The problem is that both the exectuables and development environment (header
files, libraries) often need to be present simultaneously for an extended
period.
Fixing bugs/enhancing the old versions does not stop instantaneously,
and often replacements are not available initially (or not yet fully
functional) for the applications themselves.
And, for better or for worse, often the header file names don't change
even when the underlying library has changed in an incompatible way (and
people take advantage of this sometimes to allow transitions to be possible
by a simple recompile, rather than the full "must recode to use the new
headers and API's" involved, for example, in Gnome 2. So you need to
have the same file name appear, and have some way to get two different
files....
Making one of these transitions is a lengthy process.
>
> What are we trying to solve anyway? Some applications are
> linked to older shared libraries? We have been resolvign this issue
> in distributions for _ever_. We have libc5 compatibility libraries
> (we even had libc5 and libc6 devel environments in the distribution
> contemporaneously for a while). So we keep kdelibs2 around.
>
> You say some complex applications need be present in both KDE2
> and KDE3 incarnations? That's what /etc/alternatives is designed for.
Great for single user systems. Doesn't hack it at all for shared systems,
though it may be fine for setting the default version people get unless
they take other action (and sets of applications may conflict, potentially).
>
> We can even toy with creating /usr/lib/kde2/bin;
> usr/lib/kde3/bin, and link /usr/bin/kde using the alternatives (/me
> puts on his asbestos suit now).
>
> What we do not need to do is to violate Debian tradition (and
> de facto policy) by starting to throw things into /opt.
>
>
Sure. It was a concrete suggestion of what to do, along with an
understanding that several versions may need to be installed simultaneously,
that was lacking in the discussion.
I think you need to do more than toy with creating such conventions...
- Jim
--
Jim Gettys
Cambridge Research Laboratory
Compaq Computer Corporation
jg@pa.dec.com
Reply to: