Bug#469035: libc6-i386: include mutiarch ld.conf from i386
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.
Reply to: