Re: Breaking /emul/ia32-linux for squeeze
Goswin von Brederlow a écrit :
> Aurelien Jarno <aurelien@aurel32.net> writes:
>
>> On Wed, Mar 11, 2009 at 09:55:33PM -0700, Steve Langasek wrote:
>>> On Wed, Mar 11, 2009 at 11:16:47PM +0100, Tollef Fog Heen wrote:
>>>> ]] Clint Adams
>>>> | It may be time to change packages installing files to
>>>> | /emul/ia32-linux (which violates the FHS) to use
>>>> | /usr/lib32 instead.
>>>> Could we pretty please use the multiarch paths here if we start moving
>>>> stuff around? We're going to need to patch gcc/binutils if we're to
>>>> compile stuff against those paths anyway.
>>> What transitional issues is that going to cause us if and when multiarch
>>> becomes generally available, if biarch packages start using the path now?
>>>
>> Note that i386 libc on amd64 has used once the multiarch paths. This has
>> been reverted to the current path, because there was no clear plans
>> about a transition to multiarch. I think this still applies.
>
> You couldn't compile anything for 32bit anymore.
>
>> One of the goal of multiarch is to avoid having packages containing
>> binaries of a different architecture than the one of the package (e.g.
>> i386 binaries in an amd64 package), in order to make packages of
>> different architecture co-installable. If we start to break this goal,
>> we will have packages using the multiarch path, but not co-installable,
>> for example i386 libc bundled in an i386.deb and in an amd64.deb won't
>> be co-installable.
>
> Already broken for 2 stable releases.
We are not using multiarch paths in Debian, so this has never happens.
When using standard /usr/lib paths, people are expecting that the paths
collide. When using multiarch they do not expect that, as it the goal of
multiarch.
>> IMHO, we should have a clear transitional plan to multiarch before we
>> start using multiarch path, in order to make sure we are not creating
>> problems that has to be solved later.
>
> libfoo (i386) Conflicts: lib32foo, Replaces: lib32foo
> libfoo (amd64) Conflicts: lib64foo, Replaces: lib64foo
>
> or
>
> libbla (i386) Conflicts: ia32-libs, Replaces: ia32-libs
> libbla (amd64) Conflicts: amd63-libs, Replaces: amd64-libs
>
> Adding that will let dpkg know how to handle the transition just fine.
Meaning we need to have that for each package previously available as a
biarch package. Seems to be complicated for no real gain.
Let me ask you a question: What would be the gain of using the multiarch
path for the biarch packages?
For me pushing that is the wrong way to get multiarch support in Debian.
If we want it, we need to move the main librairies to the multiarch
path. And it is something I proposed for glibc once we have proper gcc
support, and a stabilised glibc 2.9. This choice still needs to be
validated by other persons though (like the RM team).
Last but not least, what is really need to have multiarch support in
Debian is a proper support in dpkg. They are some code already done by
Tollef, they are some ideas floating around, but they are still some
design decisions to be taken, and nobody has a real patch that can be
applied to dpkg. People are pushing hard to have multiarch support, but
no one seems to care about actually writing code.
>> OTOH, as soon as we have the toolchain fully supporting multiarch path
>> support (there is a missing part in gcc, that was thought to be fixed
>> binutils [1]), I am not opposed to switch the main glibc to the multiarch
>> path.
>>
>> [1] I offered to write it, but I haven't found time yet, so a patch is
>> welcome.
>
> Binutils upstream has vetoed adding multiarch paths saying it is gccs
> job. The BTS has a simple patch for gcc using the specs file to add
> the multiarch dirs without loosing the biarch dirs.
>
> Did you have anything more complex in mind to fix this?
This patch looks a bit hackish and it has to be done for each
architecture. Mathias requested that something more automatic using
debian/multiarch.inc is done.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: