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