kdelibs: breaking the circular dependency

[Steve Langasek]

On Thu, Jan 19, 2006 at 11:04:57AM -0500, Christopher Martin wrote:
> On Thursday 19 January 2006 03:28, Steve Langasek wrote:
> > On Wed, Jan 18, 2006 at 09:16:53PM -0500, Christopher Martin wrote:
> > > Instead, the KDE team proposes to simply merge kdelibs-bin into
> > > kdelibs4c2a. The general practice of separating libraries and programs
> > > makes no sense for kdelibs, given the close two-way ties between the
> > > two. Multiple versions of the KDE libraries can't be installed
> > > side-by-side.

> > Why not?  This is not a point to be glossed over, given that this is the
> > principal reason for the rule and a significant feature of Debian
> > upgrades. If kdelibs underwent an ABI change *not* caused by the
> > compiler, why should we not expect kdelibs to allow coinstallability like
> > other library packages do?

> Even if all the filenames in kdelibs5 (for the upcoming KDE 4) are different 
> from those in kdelibs4, given that one could still not install multiple 
> copies of kdelibs-bin, users could only run KDE apps for the version of KDE 
> matching the installed kdelibs-bin.

Right, so... why should the binaries currently included in kdelibs-bin *not*
be installed under /usr/lib/kdelibs4 instead of in /usr/bin?  Are any of
these binaries things that it makes sense for a user to call directly?  And
if so, perhaps those are the only ones that belong in kdelibs-bin, and the
rest go in kdelibs4, and with luck the problem goes away?

> And furthermore, if the circular dependency is not broken, then each kdelibs 
> library package will depend on a different kdelibs-bin, which wouldn't be 
> installable.

Yes, I'm assuming that if these binaries really are bound so tightly to the
version of the kdelibs, they should be versioned just as the libraries are
-- versioned path, versioned package name.  In that case, there's no reason
at all not to merge them into kdelibs4c2a.

If changing the path of these binaries would cause a messy rebuild, then
perhaps we just make that change for kdelibs5 instead.  Then kdelibs-bin
could still be merged into kdelibs4c2a, secure in the knowledge that it
won't conflict with future versions.

> > Except that fixing the paths in kdelibs-bin to ensure co-installability
> > of packages implementing different interfaces would serve multiarch and
> > partial upgrades equally well...

> Altering the filenames in kdelibs-bin, such as /usr/bin/kioslave 
> --> /usr/bin/kioslave3, would improve the co-installability situation, but 
> I'm not volunteering to heavily patch kdelibs, many other applications, and 
> then deal with all the third-party issues.

> Unless this isn't what you mean, or there is something I'm missing.

Oh, ugh, I was assuming here that it was possible to simply change the
--exec-prefix used when building, rather than having to add a suffix for
each binary.  I agree, that doesn't sound fun :)

> The alternatives system might be able to help here, but at any given time 
> the symlinks will only be able to point to one (set of) programs, and I'm 
> not sure such a heavy use of alternatives would be wise.

Yeah, alternatives are only an answer if the different implementations each
provide the same functionality.  These do not: one set provides "foo for
kdelibs4", the other provides "foo for kdelibs5".  Since they're not
interchangeable, there's no value in using alternatives.  Indeed, their use
in such a case is explicitly contraindicated by policy.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon at debian.org                                   http://www.debian.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20060120/d39aaedd/attachment.pgp