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
Attachment:
pgpt864kp8Ezx.pgp
Description: PGP signature