Re: AMD64 for sarge [Re: <rant> Package: ftpmasters, Severity: serious, ...]

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Sam Hartman <hartmans@debian.org> writes:

>>>>>> "Stephen" == Stephen Frost <sfrost@snowman.net> writes:
>
>     Stephen> * Martin Michlmayr - Debian Project Leader
>     Stephen> (leader@debian.org) wrote:
>     >> - Some technical AMD64 questions: ftpmaster had some specific
>     >> questions about the AMD64 port they want to see answered.
>     >> Also, an LSB person recently expressed some technical concerns
>     >> (see [1]).
>
>     Stephen> We'd love to hear these questions so that we can answer
>     Stephen> them.  The LSB issue was answered on debian-amd64
>     Stephen> already.
>
> Would you mind explaining what the ia32-compatibility story will be
> for Debian amd64 both now and in the long run?  I.E. what can I expect
> to work today?  In the long run when you have dpkg-multiarch and
> everything else you want, how will it work?  How will things interact
> with other distributions?

First a glimse at the amd64 compatibility:

At the time being pure64 has links for all lib64 dirs to the
respective lib dirs. Pure64 doesn't care if software uses lib or lib64
since both end up at the same place.

That means that amd64 LSB compliant source and software will compile
and run fine on amd64 while the debian sources and libraries are not
fully compliant (since nearly all use lib instead of lib64). That
doesn't prevent sources to be made compliant but noone cares right
now.


Now, having lib and lib64 being the same has an impact on
ia32-compatibility. You can't install ia32 libs in parallel with amd64
libs since they would overwrite each other. So, instead of using /lib
for ia32 the ia32-libs package from ia64 is used on amd64 too, which
puts a handfull ia32 libs into /emul/i386-linux/ including some X and
gtk libs. Anything without rpath will find them there through the
normal ia32 ld.so in /lib (since ia32 and amd64 ld.so have different
names they don't conflict).

In summary, any sane ia32 bit binary (static or dynamic without rpath)
is expected to work. ia32 libs are expected to work if you install it
to /emul/i386-linux/ or if you don't have the amd64 counterpart
installed. Installing and overlapping files between packages are your
problem.



In the future multiarch hopefully takes hold and will bring a few
changes:

1. libs are installed into lib/<arch>-<kernel>, includes are handled
   similar if needed
2. /lib, /lib32 and /lib64 will be completly empty except for the
   ld.so for each arch
3. It is planed to have a ldconfig wrapper that can create
   compatibility links in /lib, /lib32 and/or /lib64 for compatibility
   with rpath binaries, broken configure scripts and the existing
   LSB. But that would be optional and hopefully the LSB will adapt to
   the saner layout.

Once /lib64 is depopulated enough the link in pure64 can be converted
back to a real directory or removed completly as can the lib32 dir on
other archs.

The transition from uniarch to multiarch is suposed to be transparent
to the user. Once you update to a multiarch dpkg and apt the extra
architectures become instantly available. As to how you configure what
archs you want (of those that you can run) is still open. With the
biarch dpkg you could just edit the subarchtable to reflect your
preferences.

MfG
        Goswin