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/
Attachment:
signature.asc
Description: Digital signature