ia32 user space on ia64, et al
I'm currently thinking through the issues involved in getting ia64 support
from where it is now to something we can release joyfully. One of the big
issues is how we should support ia32 user space applications and libraries
on ia64. Since this is perhaps only the first of several potential multi-
architecture situations facing us, I'd like to help motivate a general solution
to the problem.
Other distributions are handling this for ia64 in various ways, none of which
seem "right" to me. TurboLinux has a single .rpm that delivers a subset of
the ia32 libraries from their distribution repackaged to install in a
subdirectory instead of in /. Redhat apparently has updated RPM to do
on-the-fly path translation for ia32 binary .rpm's when they are installed on
an ia64 system. In all cases, the dynamic loader is smart enough to pick the
right library routine from the right architecture once ld.so.conf is loaded
with the real paths to all the libraries in question.
I would love to see Debian adopt a solution that allows use of unmodified
ia32 (i386 in Debian lingo) packages on ia64 systems... and which is general
enough to handle the other multi-arch flavors we can anticipate.
It seems to me that what we really want is a combination of our package
management toolset understanding how to handle multi-arch machines, and
changes in our shared library packaging to avoid conflicting paths. More
specifically, what I've thought about includes the following changes:
- all shared library packages deliver files to architecture-specific
paths on the target system. In other words, /lib-i386 instead
of /lib (using whatever pathing convention feels right and could
be adopted by a future FHS version).
- dpkg allows installation of packages from more than one architecture
tree on a given system
- apt knows to give preference to the native architecture when using
'apt-get install' and so forth on a multi-arch machine.
- decide whether we need to care about conflicting executables. The
big issue is clearly getting the shared libs all installed without
conflict... is there any case where having /usr/bin/<blah> installed
for more than one arch is important? I haven't thought of any such
cases yet. It seems to me that if there's a native package, you want
to use it and there should be no conflicts?
Of course, doing this is a lot of work. Clearly, other distributions
supporting ia64 have chosen to take more expedient paths. If there's a good
hack I haven't thought of that won't make us all ill, I'd be pleased to
consider it. I'm not thrilled by the path translation on the fly, but it is
clearly an alternative we could consider, for example.
I intend for ia64 to be released stable with woody. I would love for the ia32
user space "problem" to be resolved cleanly by then, but I'm not expecting
miracles. If I have to hack something interim while waiting for a general
solution to be implemented, I can probably live with that.
Discussion?
Bdale
Reply to: