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

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***!


 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? 

	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   <srivasta@debian.org>  <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

Reply to: