[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 64-bit packaging details

Arnd Bergmann wrote:
> Exactly. Note that nowadays, all the important architectures
> support running i386 binaries with qemu, but amd64 is the only
> one that can run them with native speed. It may become 'interesting'
> if qemu or ia64 start supporting amd64 binaries. Imagine a 
> 64 bit power mac with /lib, /lib64, /libosx, /libx86 and /libamd64 ;-)

[Drift: On the one hand there is the /lib<qual> specification.  On the other
there is /emul/ specification.  They seem to be at odds with each
other.  Perhaps someone could enlighten me as to the comparison and

> Seriously, for non-native emulated binaries, having a full
> file system hierarchy below /emul/<arch>-<os>/, e.g.
> /emul/i386-linux/, probably makes more sense.

> > But doing so with Debian is an exercise left for the reader.

Recently I posted a note in debian-ia64 which is related to this
problem.  It describes using an alternative chroot methodology to
manage emulation binaries other than the currently provided ia32-libs
package.  Using a chroot environment allows you to manage the
emulation layer using a native, but separate, dpkg instantiation.  For
me personally it works pretty well and is the best I can do right now
since dpkg does not understand about multiple architectures on the
same machine.  I am sure there is applicability to x86-64.


But this is not completely without problems.  In the discussion of
that thread talking about OpenOffice I describe why the difference
between binaries and scripts are significant.


Basically a script probably won't be in the emulation layer if the
interpreter is provided outside of it.  Which means you can get into a
case where script and the binaries it is running don't have the same
view of the filesystem.  They will be out of sync.  The OpenOffice
scripts were looking for things which only existed in the emulation
layer and not outside of it and so failed to work out of the box like
that.  I used symlinks to work around this for the specific case of
OpenOffice.  But it is not as clean as I would like it to be.

> The feature is also interesting for i386, because it can make it easy
> to support i686 or i486 optimized packages. The relationship 
> between amd64 packages and their i386 counterparts is
> not all that different from the i686 vs. i386 relationship.

This topic comes up often on debian-devel.  Always a hotbed of
discussion.  Since there has never been a good resolution of the
i386/i686 problem I fear that there will not be a good resolution to
the i386/x86-64 problem in the near future either.


Attachment: pgpTPzlmGjgGK.pgp
Description: PGP signature

Reply to: