Re: Breaking /emul/ia32-linux for squeeze
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.
> 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.
> 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?
MfG
Goswin
Reply to: