[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 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?

 Jim> Yes, shared libraries often help.  But that is only one aspect of the
 Jim> problem, maybe the easiest.

	Ok, so we shall take it one step at a time. Older
 applications, not part of KDE/Gnome, but linked against KDE/Gnome
 libraries, continue to work.

 Jim> The problem is that both the exectuables and development
 Jim> environment (header files, libraries) often need to be present
 Jim> simultaneously for an extended period.

	Yes. And we prvided both libc5 and libc6-dev package at the
 same time for a longish period.  You have any concrete reasons why
 that should not work again, or is this just a vague general rumbling
 of potential problems? 

 Jim> And, for better or for worse, often the header file names don't
 Jim> change even when the underlying library has changed in an
 Jim> incompatible way (and people take advantage of this sometimes to
 Jim> allow transitions to be possible by a simple recompile, rather
 Jim> than the full "must recode to use the new headers and API's"
 Jim> involved, for example, in Gnome 2.  So you need to have the same
 Jim> file name appear, and have some way to get two different
 Jim> files....

	Hmm. This would require some tinkering with application
 Makefiles, or use the /etc/alternatives mechanism for include dirs, 
 Note that shoving things into /opt would not make things any easier
 (indeed, having a default set of libs and includes in the usual
 places, the Debian approach, is probably simpler on Makefiles).

	I suspect that rather than mucking weith /etc/alternatives for
 the dev environment we shall restict a machine to having one or the
 other environment, but that depends on the maintainers.

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

 Jim> Great for single user systems.  Doesn't hack it at all for
 Jim> shared systems, though it may be fine for setting the default
 Jim> version people get unless they take other action (and sets of
 Jim> applications may conflict, potentially).

	In what way is this inereior than the blecherous /opt
 proposal? Or are you being contrarian just because of a NIH syndrome?
 If both sets of packages are installed, people can still chose the
 non default set equally easily in this proposal.  I fail to see why
 this solution doesn't hack it but the /opt solution (which requires
 every single darned use to modify their $PATH some how did).

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

 Jim> Sure.  It was a concrete suggestion of what to do, along with an
 Jim> understanding that several versions may need to be installed
 Jim> simultaneously, that was lacking in the discussion.

 Jim> I think you need to do more than toy with creating such conventions...

	This is not the place, nor the personnel, to discuss concrete
 details. The relevant developers, in conjunction with each other,
 this group, and policy, shall firm out the details of how Debian
 deals with KDE and Gnome issues. I am not the person in charge.

	 This molehill has been made into too much of a mountain.

 Boob's Law: You always find something in the last place you look.
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: