Christopher Martin
2006-Jan-19 02:17 UTC
[pkg-kde-talk] kdelibs: breaking the circular dependency
Hello, There exists a (necessary) circular dependency between kdelibs-bin and kdelibs4c2a. kdelibs-bin is linked to kdelibs4c2a. Also, every KDE application needs the binaries in kdelibs-bin to function properly (it contains very basic services without which a KDE application will be useless, if it starts at all). Yet hardly any packages depend on kdelibs-bin. So to break the circular dependency by removing kdelibs4c2a''s dependency on kdelibs-bin would require that all KDE packages be re-uploaded with a kdelibs-bin dependency manually added. Not fun. And every KDE-using system would still need both kdelibs-bin and kdelibs4c2a, so the gain/pain ratio would be small. 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. And this close relationship means that KDE was never a good candidate for multiarch anyway (only one copy of kdelibs-bin means KDE applications of only one architecture), so mixing programs and libs in one package won''t cost anyone anything, in practice. But since this change will stretch policy, which prefers that libraries and programs be split, we''d like the blessing of the Release Team before committing ourselves. For the rare package which actually depends on kdelibs-bin, kdelibs4c2a will still "Provides: kdelibs-bin". So the ''transition'' should be utterly painless, and require no work or changes by anyone (beyond the obvious kdelibs packaging changes). The removal of this circular dependency should, hopefully, make future transitions easier, avoiding difficulties such as those encountered by users during the Woody to Sarge upgrade. Post-Etch, KDE 4 will require a kdelibs transition, and this will be tied to a move from Qt3 to Qt4. Getting kdelibs'' circular dependencies straightened out before Etch may help later on. This message follows a slightly more detailed discussion, starting here: http://lists.alioth.debian.org/pipermail/pkg-kde-talk/2006-January/000446.html Please CC pkg-kde-talk@lists.alioth.debian.org on responses. 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/20060118/85627df3/attachment.pgp
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?> And this close relationship means that KDE was never a good candidate for > multiarch anyway (only one copy of kdelibs-bin means KDE applications of > only one architecture),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...> so mixing programs and libs in one package won''t cost anyone anything, in > practice. But since this change will stretch policy, which prefers that > libraries and programs be split, we''d like the blessing of the Release > Team before committing ourselves.Sorry, the only blessing that the release team as release team has to offer is "this doesn''t suck so bad that we''ll refuse to release it". While I can give you that blessing, for a real endorsement you should discuss this on debian-devel where technical discussions belong.> The removal of this circular dependency should, hopefully, make future > transitions easier, avoiding difficulties such as those encountered by > users during the Woody to Sarge upgrade. Post-Etch, KDE 4 will require a > kdelibs transition, and this will be tied to a move from Qt3 to Qt4. > Getting kdelibs'' circular dependencies straightened out before Etch may > help later on.Yes, that definitely sounds like a benefit. If you''re looking for an optimal solution for upgrade support, though, I think we still need to carefully consider the question of ABI co-installability. 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@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/20060119/0f5f1b0b/attachment.pgp
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. 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. We could break the circular dependency, but that brings us back to the problem of re-uploading all KDE applications to depend on kdelibs-bin. Even if this were done then at best developers could build against their choice of kdelibs versions, but the instant they tried to run a program built against a kdelibs that didn''t have a corresponding kdelibs-bin installed, they''ll hit _serious_ problems. As a development platform, therefore, this would be of limited use. Bill Allombert suggested a system wherein kdelibs4c2a becomes a metapackage depending on kdelibs-bin and kdelibs4c2a-lib, which would preserve the program/lib separation and eliminate circular dependency, but that would hardly solve the basic problem of it being possible to install only one kdelibs-bin at a time, so I don''t feel that the added complexity of this system would be justified by the few benefits.> > And this close relationship means that KDE was never a good candidate > > for multiarch anyway (only one copy of kdelibs-bin means KDE > > applications of only one architecture), > > 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. 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.> > so mixing programs and libs in one package won''t cost anyone anything, > > in practice. But since this change will stretch policy, which prefers > > that libraries and programs be split, we''d like the blessing of the > > Release Team before committing ourselves. > > Sorry, the only blessing that the release team as release team has to > offer is "this doesn''t suck so bad that we''ll refuse to release it". > While I can give you that blessing, for a real endorsement you should > discuss this on debian-devel where technical discussions belong.That''s quite fair. I appreciate your thoughts. 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/20060119/2629ec04/attachment.pgp
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@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
On Friday 20 January 2006 08:52, Steve Langasek wrote:> 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 :)Ah, right, dumping them under /usr/lib/foo. I knew there was some option I was overlooking :)> > 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?Some programs can be called directly by users, but some of these are also generally necessary for KDE apps to run. It''s messy. We could add /usr/lib/kdelibs4 to the path in the "startkde" script, so the programs launched from within the full KDE environment would work. But then KDE applications launched from GNOME, etc. would still have trouble. I don''t know how distros like SuSE deal with this, since they put KDE in /opt/kde3/{bin,lib,...} or something similar. Presumably they simply add /opt/kde3/bin to their basic PATH, but this isn''t the sort of solution I imagine Debian would want to employ. I couldn''t say definitively offhand whether an attempt to "hardwire" a path through patching would be productive.> 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.Indeed, KDE 4 will provide us with an opportunity to reassess everything. Perhaps the move to KDE 4 would be a good point to implement major changes (perhaps to cope specifically with multiarch), while simply merging kdelibs-bin into kdelibs4c2a for now, in order to smooth the transition to KDE 4. But we''ll consider to ponder the issue. We have decided that the next kdelibs upload (soon...) won''t make any major changes. Thanks again for your input. 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/20060120/46003f85/attachment.pgp