Re: [kde] setting an /opt precedent
>>"Jim" == Jim Gettys <firstname.lastname@example.org> writes:
Jim> The X protocol has remained strictly compatible since X11 shipped
Jim> in ***1988***!
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
So why would keeping older shared libs around until they are
no longer needed not a solution for this issue?
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.
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.
Prejudice: A vagrant opinion without visible means of
support. Ambrose Bierce
Manoj Srivastava <email@example.com> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C