Re: Breaking /emul/ia32-linux for squeeze
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.
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.
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.
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.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: