[pkg-kde-talk] Re: kdelibs4c2a <-> kdelibs-bin circular dependency - advice requested

[Christopher Martin]

On Wednesday 18 January 2006 08:51, Bill Allombert wrote:
> > One solution would be to eliminate the kdelibs-bin package, merging it
> > into kdelibs4c2a. But this violates the general practice of not
> > shipping binaries in a library package, so there would have to be some
> > general understanding about what we were doing before any such merge,
> > to avoid too many later complaints, etc. (kdelibs4c2a is already a
> > massive collection of libraries, and isn't really designed to allow
> > clean side-by-side installs of different KDE versions in the same
> > hierarchy, so I don't think we'd lose too much flexibility in practice,
> > but still...)
>
> I think the core issues are whether 1) kdelibs4c2a needs kdelibs-bin to
> work

Yes. KDE apps will not work without kdelibs-bin installed. kdelibs-bin 
contains basic KDE services that apps expect to have running or available - 
dcop (the IPC system), I/O services for browsing file systems, http, etc.

I tried running a KDE app in an environment where I'd forcibly purged 
kdelibs-bin, and while it did run, it didn't do anything. The file dialogs 
were empty, I got an endless series of warnings, etc. It was useless.

> 2) kdelibs-bin needs kdelibs4c2a

Yes.

> 3) it is possible to write a program that use kdelibs4c2a but do not need
> kdelibs-bin.

I suppose it might be possible somehow, but it wouldn't be a normal KDE 
application, certainly. For all intents and purposes, all KDE apps need 
both -bin and the libs.

> In any case there is a simple technical solution: make kdelibs4c2a
> a dummy package that depends on kdelibs-bin and kdelibs4c2a-lib, where
> the libraries are actually in kdelibs4-lib. Keep the shlibs pointing
> to kdelibs4c2a, but tweak the build process so that kdelibs-bin depend
> only on kdelibs4-lib.
>
> Depending on the answer to 1) and 3) above, it might be possible to
> transition to scheme where all KDE packages depend on kdelibs-bin
> and then get rid of kdelibs4-lib.

Yes, that would work. But I view this as more complex than necessary. Given 
the answers to 1), 2) and 3), I view merging kdelibs-bin into kdelibs4c2a 
as simpler, and involving virtually no work on the part of 3rd party 
maintainers (only a handful of packages depend on kdelibs-bin directly, and 
the new kdelibs4c2a can Provide: kdelibs-bin).

Since the separation between kdelibs-bin and kdelibs4c2a is not functional 
(i.e. they are always used together) keeping them apart seems unnecessary, 
and (as far as I can tell) only satisfies the notion that libraries and 
programs should be separate, even when, in this case, they are not used 
separately. But if people view my solution as too radical, then your 
proposal seems OK at first consideration.

> > But is this really necessary? You dealt with KDE woody --> sarge
> > upgrade issues. How much of a problem is the kdelibs circular
> > dependency? Any advice or suggestions on how to proceed or what to keep
> > in mind would be welcome.
>
> This is hard to know, but the fact is that we will not be able to fix
> that on a short time frame and we have to deal with dependencies in
> stable release.

Yes, it would be nice to have this fixed, so the post-Etch KDE4 (using Qt4) 
transition is less messy.

> PS: is Chris Cheney MIA ?

He certainly isn't active in KDE packaging, so unless there is some other 
area of the project where he's active, I'd say yes, he's MIA.

Cheers,
Christopher Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 249 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20060118/88e131b3/attachment.pgp