Christopher Martin
2006-Jan-16 01:50 UTC
[pkg-kde-talk] kdelibs4c2a <-> kdelibs-bin circular dependency - advice requested
Hello, As you''re aware, there exists a clear circular dependency between kdelibs4c2a and kdelibs-bin. The binaries in kdelibs-bin link to the libraries in kdelibs4c2a. kdelibs4c2a has libraries which work extremely closely with the binaries in kdelibs-bin. Moreover, extremely few KDE packages depend on kdelibs-bin directly. They all assume that it gets pulled in by kdelibs4c2a, and during operation they do all assume that the binaries in kdelibs-bin are available, i.e. without kdelibs-bin nothing works. So this makes the circle seem unbreakable, since re-uploading every KDE package, making them all depend on kdelibs-bin manually, would not be pleasant. 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...) 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. Thanks, 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/20060115/f9ea615b/attachment.pgp
Bill Allombert
2006-Jan-18 13:51 UTC
[pkg-kde-talk] Re: kdelibs4c2a <-> kdelibs-bin circular dependency - advice requested
On Sun, Jan 15, 2006 at 06:35:18PM -0500, Christopher Martin wrote:> Hello, > > As you''re aware, there exists a clear circular dependency between > kdelibs4c2a and kdelibs-bin. The binaries in kdelibs-bin link to the > libraries in kdelibs4c2a. kdelibs4c2a has libraries which work extremely > closely with the binaries in kdelibs-bin. Moreover, extremely few KDE > packages depend on kdelibs-bin directly. They all assume that it gets > pulled in by kdelibs4c2a, and during operation they do all assume that the > binaries in kdelibs-bin are available, i.e. without kdelibs-bin nothing > works. > > So this makes the circle seem unbreakable, since re-uploading every KDE > package, making them all depend on kdelibs-bin manually, would not be > pleasant.Well technically that could have been done as part of the c++ transition, could not it ?> 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, whether 2) kdelibs-bin needs kdelibs4c2a and whether 3) it is possible to write a program that use kdelibs4c2a but do not need kdelibs-bin. I suspect 2) is true, but am unsure about 1) and 3). 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.> 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. This also break the dependency expectation: kdelibs-bin can be installed before kdelibs4c2a. This particular circular-dep does not seems too messy to fix so we should settle on a clean solution and do it. The question being, what the packages are doing really ? what are the real dependencies ? Cheers, Bill. PS: is Chris Cheney MIA ?
Christopher Martin
2006-Jan-18 17:43 UTC
[pkg-kde-talk] Re: kdelibs4c2a <-> kdelibs-bin circular dependency - advice requested
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 > workYes. 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 kdelibs4c2aYes.> 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
Adeodato Simó
2006-Jan-18 17:54 UTC
[pkg-kde-talk] Re: kdelibs4c2a <-> kdelibs-bin circular dependency - advice requested
* Christopher Martin [Wed, 18 Jan 2006 12:42:27 -0500]:> 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.Weeell, it''d be an option, but then we have this liiittle section from Policy: 8.2. Run-time support programs ------------------------------ If your package has some run-time support programs which use the shared library you must not put them in the shared library package. If you do that then you won''t be able to install several versions of the shared library without getting filename clashes. Instead, either create another package for the runtime binaries (this package might typically be named `<libraryname>-runtime''; note the absence of the <soversion> in the package name), or if the development package is small, include them in there. Note the "must not"... Cheers, -- Adeodato Sim? dato at net.com.org.es Debian Developer adeodato at debian.org <dato> http://lists.ubuntu.com/archives/ubuntu-news/2005-December/000033.html <dato> these ubuntu-news are all about warm fuzzy feelings, how much we rock and, specially, love each other. <isaac> es como la distribucion de los teletubbies <dato> that may be the best description of ubuntu I''ve ever heard
Brian Nelson
2006-Jan-18 19:22 UTC
[pkg-kde-talk] Re: kdelibs4c2a <-> kdelibs-bin circular dependency - advice requested
Adeodato Sim? <dato@net.com.org.es> writes:> * Christopher Martin [Wed, 18 Jan 2006 12:42:27 -0500]: > >> 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. > > Weeell, it''d be an option, but then we have this liiittle section from > Policy: > > 8.2. Run-time support programs > ------------------------------ > > If your package has some run-time support programs which use the > shared library you must not put them in the shared library package. > If you do that then you won''t be able to install several versions of > the shared library without getting filename clashes. > > Instead, either create another package for the runtime binaries (this > package might typically be named `<libraryname>-runtime''; note the > absence of the <soversion> in the package name), or if the development > package is small, include them in there. > > Note the "must not"...I think that''s a stupid requirement in policy (and means the Qt4 packages violate policy). kdelibs don''t coexist nicely anyway AFAIK, so the rationale for that requirement doesn''t apply. -- Captain Logic is not steering this tugboat.
Christopher Martin
2006-Jan-18 19:30 UTC
[pkg-kde-talk] Re: kdelibs4c2a <-> kdelibs-bin circular dependency - advice requested
On Wednesday 18 January 2006 12:54, Adeodato Sim? wrote:> Weeell, it''d be an option, but then we have this liiittle section from > Policy: > > 8.2. Run-time support programs > ------------------------------ > > If your package has some run-time support programs which use the > shared library you must not put them in the shared library package. > If you do that then you won''t be able to install several versions of > the shared library without getting filename clashes. > > Instead, either create another package for the runtime binaries > (this package might typically be named `<libraryname>-runtime''; note the > absence of the <soversion> in the package name), or if the development > package is small, include them in there. > > Note the "must not"...True, we''d probably want to get Release Team blessing. In this case, I don''t think that the rationale ("you won''t be able to install several versions of the shared library") applies, since KDE isn''t designed for multiple, side-by-side installs; kdelibs4 will never be installable alongside kdelibs5. The need for KDE binaries (currently in kdelibs-bin) precludes it (amongst many other things). The binaries are so closely tied to the libraries in KDE, that the separation doesn''t give anyone any sort of advantage, added flexibility, etc. Since they already depend on each other, eveyone has both installed anyway. And re-uploading every application with a kdelibs-bin dep added... I don''t want to do that, though maybe for KDE4 we could try to change the policy... but again, it wouldn''t actually help anything or result in any improvements or advantages. But yes, we''d need to establish some sort of understanding that KDE was an exception to the policy before proceeding. And the KDE team would have to support the idea - not just me :) Chris
Adeodato Simó
2006-Jan-18 19:34 UTC
[pkg-kde-talk] Re: kdelibs4c2a <-> kdelibs-bin circular dependency - advice requested
* Christopher Martin [Wed, 18 Jan 2006 14:30:35 -0500]:> But yes, we''d need to establish some sort of understanding that KDE was an > exception to the policy before proceeding. And the KDE team would have to > support the idea - not just me :)I certainly don''t reject it. Only wanted to point out that such section of policy would have to be taken care of. (And perhaps a proper explanation in the changelog may qualify for "take care of".) Cheers, -- Adeodato Sim? dato at net.com.org.es Debian Developer adeodato at debian.org He has never been known to use a word that might send a reader to the dictionary. -- William Faulkner (about Ernest Hemingway)
Bill Allombert
2006-Jan-20 22:18 UTC
[pkg-kde-talk] Re: kdelibs4c2a <-> kdelibs-bin circular dependency - advice requested
> 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.I have taken a bit of time to look at the packages. One issue I am unsure is how kdelibs4c2 use kdelibs-bin ? I will assume the library forks kdelibs-bin daemons. Currently kdelibs4c2 is a pure librarie packages. It has an exact-version depend on kdelibs-bin and kdelibs-bin as a >= version depend on kdelibs4c2. This is messy because the exact-version dependency cannot be satisfied during upgrade, so there is a definite possibility kdelibs4c2 launch a old, incompatible, daemon. We normally want to allow several major versions of pure libraries packages to be co-installable, however the same-version dependencies prevent that. However if multi-arch is implemented, there still the possibility to have both 32bit and 64bit at the same time. As far as I understand the design of KDE IPC allows 32bit and 64bit processes to work together, so it might make sense to install kdelibs4c2-32bit, kdelibs4c2-64bit and kdelibs-bin-32bit. If you merge kdelibs-bin in kdelibs4c2, then kdelibs5 will have to conflict with kdelibs4c2. I don''t think this is a big deal given the exact-version depdends will forbid kdelibs4c2 and kdelibs5 to be co-installable. Alternatively, you can fix the co-installability problem by versioning the path to the binaries, e.g. moving them to /usr/lib/kdelibs4/ and make sure the libraries use the correct path. Cheers, Bill.
Pierre Habouzit
2006-Jan-20 22:40 UTC
[pkg-kde-talk] Re: kdelibs4c2a <-> kdelibs-bin circular dependency - advice requested
Le Ven 20 Janvier 2006 23:17, Bill Allombert a ?crit :> Alternatively, you can fix the co-installability problem by > versioning the path to the binaries, e.g. moving them to > /usr/lib/kdelibs4/ and make sure the libraries use the correct path.honnestly, there is no point in doing that. This would make the packaging even more painfull that it is now, with almost no gain. The only way to achieve reall co-instability is to do as gentoo does : make KDE live in /usr/kde/x.y/ which would be a major policy violation, and which makes no sense at all. your arguments about multiarch *are* valid and deserve some pondering (especially since users may want a 32bits konqueror to be able to use macromedia flash plugin, or sun''s java plugin...). but honnestly, beeing able to co-install different kdelibs *versions* has no point at all, since no one would really take advantage of this. In the KDE world, most applications migrate to the new kdelibs/kdebase with each new KDE release. I''ve really problems to think of a situation where co-instability would really help any user. Moreover, it''s not really a feature that our users want. Developpers have their own checkout of kde-HEAD in their home, and adjust their KDE_PATH to $HOME/kde-head/ and the trick is done, they have two version of KDE on the same system. -- ?O? Pierre Habouzit ??O madcoder@debian.org OOO http://www.madism.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20060120/819cc103/attachment.pgp
Bill Allombert
2006-Jan-21 12:23 UTC
[pkg-kde-talk] Re: kdelibs4c2a <-> kdelibs-bin circular dependency - advice requested
On Fri, Jan 20, 2006 at 11:40:25PM +0100, Pierre Habouzit wrote:> Le Ven 20 Janvier 2006 23:17, Bill Allombert a ?crit : > > Alternatively, you can fix the co-installability problem by > > versioning the path to the binaries, e.g. moving them to > > /usr/lib/kdelibs4/ and make sure the libraries use the correct path. > > honnestly, there is no point in doing that. This would make the > packaging even more painfull that it is now, with almost no gain.Well, if you are not interested in supporting co-installability, then I support the move to merge kdelibs-bin to kdelibs4c2a. This is the only simple solution that remove the real problem, namely the exact-version dependency of kdelibs4c2a on kdelibs-bin. Cheers, Bill.