Re: Breaking /emul/ia32-linux for squeeze
Aurelien Jarno <email@example.com> 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.
> 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
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.
> 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 ), I am not opposed to switch the main glibc to the multiarch
>  I offered to write it, but I haven't found time yet, so a patch is
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?