Bug#469035: libc6-i386: include mutiarch ld.conf from i386
Javier Serrano Polo a écrit :
> 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.
That's wrong, there is a way to build them to get them using the
multiarch path. The version in unstable doesn't use the multiarch paths.
>> 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.
No I suggest to do a "echo path > /etc/ld.so.conf.d/path" manually.
>> 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.
There is an implicit support for those paths. There is no support for
libc6-i386 being the multiarch i386 libc6 on an amd64 system.
The correct one is libc6_.._i386.deb installed on an amd64 system.
>> 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.
As long as they are not official, I don't care about the problem they
can cause. Officialising them means we have to care about them.
>> 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.
No. Multiarch does not remove the architecture of a package. Instead it
should allow the installation of a package from a different architecture
than the one of the system.
> 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.
If you don't know how to handle the conflict, the best is to not create
conflicts. And again, if we officially support the ld.so configuration
we then implicitely support such package.
>> 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.
If you got a working multiarch system, then please share your patches.
What doesn't work:
- binutils is not able to link a library against another one library in
a multiarch path.
- dpkg has no notion of multiarch, and thus is not able to install a
package for a different architecture than the one of the system, and
correctly handle dependencies in that case.
- libraries even when using multiarch path won't be installable in more
than one architecture: some of them have binaries which would conflict,
the other will have conflict with the /usr/share/doc files.
That's the minimal requirrements to say you have a multiarch system.
Full support in apt would be the next step.
And a precision: multiarch is not simply using the multiarch path. It's
allowing packages from different architectures to be installed on a same
system. And that includes dependencies handling and apt support. If by
multiarch support you simply mean a package using multiarch support,
that's something people have for a very long time. But that's not really
useful.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: