[Gllug] Debian 32/64 bitness (was Memory usage)

Thu Oct 13 19:25:19 UTC 2005

>>> On Thu, 13 Oct 2005 17:17:29 +0200, "Martin A. Brooks"
>>> <martin at hinterlands.org> said:

[ ... the "Debian way"s of running 32 bit x86 apps in a 64 bit x64
environment ... ]

martin> [ ... ] What does dpkg and/or apt have to do with
martin> implementation of execution of 32 bit programs in a 64
martin> bit environment? [ ... ]

Well, other distributions based on RPM (which has some issues
for sure, but quite as bad as DPKG/APT) don't have to use the
same workarounds.

In theory, in theory indeed, one can install a many-platform
system, using somthing like: 

  /usr/share			platform independent
  /usr/fedora-linux-i386/lib	platform dependent
  /usr/debian-netbad-amd64/lib	platform dependent
  /usr/apple-darwin-ppc/lib	platform dependent
  /usr/ibm-aix-power5/lib	platform dependent

and similarly for '/lib' and so on, and the rudiments of such a
logic are in the filesystem shape standard and in the GNU
autoconf tools (check 'ls /usr') even if the order of the
''vendor'', ''API'' and ''ABI'' fields is arguably wrong.

The issue then: can you do a multi platform install? That is one
for example where there are _two_ 'libc.so', one for 32 bit and
one for 64 bit, installed at the same time. Yes, of course, if
your package and dependency managers both support it.

>> For example, ask yourself: why is the major version of many
>> '.deb's repeated as a suffix to the package name? Why not
>> add the name of the architecture as another suffix? :-)

martin> You've still lost me, could you explain your point in
martin> simpler terms, please?

The problem here is: suppose you have programs that want to use
two different API/ABI versions of the same library, let's say
the Berkeley DB library.

Easy! Just install both the relevant packages, and because each
API/ABI versions has a different set of numbers after ".so"
everything is all right.

  This is desirable in order to have the ability to boot the
  same disc on different architectures (something that did
  happen sometimes when one had rmeovable disc packs), or to
  share the same installed tree over the network with clients
  with different architectures. An AMD64 machine is a special
  case of the former situation, as in effect it is both an
  'amd64' and a 'i386' CPU at the same time.

  The reason why multiplatform installs haven't been well
  targeted is lazyness, induced by the x86 monoculture that has
  infected so many environments, and secondarily by cheap disc
  space. For example, as long as one installs the base 'i386'
  packages, one can boot it on any PC and share it with any PC.

Why then on my !"£$%^ Debian system I have these:

----------------------------------------------------------------
i   356kB  807kB  4.1.25-18  4.1.25-18 libdb4.1
i   368kB  868kB  4.2.52-20  4.2.52-20 libdb4.2
i   <N/A>  979kB  4.2.52-19  4.2.52-19 libdb4.2++
i   399kB  926kB  4.3.28-3   4.3.28-3  libdb4.3
i   427kB 1020kB  4.3.28-3   4.3.28-3  libdb4.3++c2
----------------------------------------------------------------

Note, the point here is that the packages are called:

  libdb4.1-4.1.25-18_i386.deb
  ...
  libdb4.3-4.3.28-3_i386.deb

and so on. Why aren't they called instead:

  libdb-4.1.25-18_i386.deb
  ...
  libdb-4.3.28-3_i386.deb

and so on, and then install different versions of a package with
the same base name? Well, because you cannot if you use DPKG/APT.

Similary, if you have both

  libdb-4.3.28-3_i386.deb
  libdb-4.3.28-3_amd64.deb

you would want to be able to install them all, as after all they
would live in different directories. Well, you cannot if you use
DPKG/APT.

As the official HOWTO summarily says:

  https://Alioth.Debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id271960

   «This is because you can't mix 32bit applications and
    64bit libraries. You would also need the 32bit versions
    if the libraries to run a 32bit application.»

Now admittedly it is not quite as simple as ''install them all''
but after all the Linux kernel has support for multiple ELF
executable types, and from there it is not that hard to have
multiple loaders etc., and with some hack or another other
distros handle it.

The basic problem is that the DPKG/APT combination only looks at
the package base name, not at all three/four parts of the full
name, so if you have 'libdb-4.3.28-3_i386.deb' and try to
install 'libdb-4.3.28-3_amd64.deb' that is a replacement/upgrade
(same base name), not a separate/parallel install.

For this reason Debian package names have the major version
appended as a suffix to the base package name, and they even
have, as in this case:

i 427kB 1020kB 4.3.28-3 4.3.28-3 libdb4.3++c2

the ABI version of the C++ library they depend upon appended to
the base name; sooner or later we shall see the architecture
type appended too, and why not? :-(

And indeed this _has happened_:

  https://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id271987

   «There is already a minimal set of IA32 libraries packaged
    for use in a 64bit Debian system. Simply do an 'apt-get
    install ia32-libs' and you will be able to run most 32bit
    binaries within your system.»

as 'ia32-libs' is just a compilation of the contents of existing
'_x86.deb' packages, with a different, architecture dependent name.

Note that even RPM based distros like RedHat's have ugliness
like their 'compat-*' ABI backwards compatibility compilations,
purely out of expediency, even if these could just be lists of
packages with older version numbers, because 'rpm' does
distinguish between '-i' (install without replacing) and '-U'
(replace if this can be seen as an upgrade).

-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug