El dg 11 de 05 de 2008 a les 19:21 +0200, en/na Aurelien Jarno va escriure: > Those packages are still experimental and not designed to be uploaded to > the Debian archive until full multiarch support is available in Debian.
That gtk+2.0 version's in unstable. pango1.0's already in testing. > I really expect that people able to recompile such packages with > multiarch enabled are also able to create this small one-liner file in > /etc/ld.so.conf.d/. But I don't expect people able to use those packages to create it. I hope you aren't suggesting to include the config file in every recompiled package. > The name of the file is not my only concern. Adding this file into > /etc/ld.so.conf.d/ means that we implicitly support it, and so we should > support all the consequences, and provide an upgrade path from lenny to > lenny + 1. The paths are already supported for lenny. There's an implicit support. I'm asking for an explicit support in the ld.so.cache. > Experience shows that users are very imaginative when you provide a > feature. I already imagine packages using multiarch paths, but with a > dependency on libc6-i386. Don't imagine. They already exist. They aren't just official. > How do you then handle the conflict between > the plain i386 version of this package using multiarch paths and > installed on an amd64 system, and the i386 version of this package also > using multiarchs path but bundled into an amd64 package? They will use > the exact same paths. Small clarification: multiarch is (or should be) made of all-architecture packages. I don't know how to handle the conflict if I don't know how you're gonna handle plain i386 versions. Anyway, the problem would be having official packages with libraries in multiarch paths, not the ld.so configuration. That file makes no harm. > The transition to multiarch will be really painful, and until we have a > clear view on how to do it, I prefer to avoid thinking of the nth step, > and instead concentrate on the first steps. The first step being getting > multiarch support added to binutils and dpkg. One other step is to split > the glibc between libraries and binaries, this work is planned for glibc > 2.8 and will be tested in experimental first. The impression I'm getting is you guys don't really know how multiarch will work. I have multiarch already working (more than two months) and I'm still waiting for reports of what doesn't work. > So in short, this bug is a wontfix, at least for lenny. Too bad. I hope you understand my expectations regarding multiarch, having a working solution already available. Thanks for the quick response. Please let's move this discussion to an appropriate list if you want to continue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
