Goswin von Brederlow wrote:
> Bob Proulx writes:
> > Red Hat has implemented special case biarch support. Debian has not
> > implemented either but the goal is to implement multiarch.
>
> So under red hat you can actualy do: [whatever dpkg's -i is for rpm]
>
> rpm -i libfoo_i386.rpm
> rpm -i libfoo_amd64.rpm
> rpm -i bar_i386.rpm baz_amd64.rpm
>
> where bar and baz both need libfoo?
Correct. (Within the limits of the simplications.) That is exactly
how it works on Red Hat.
Here is a real example using zlib to make for concrete discussion. It
may be a little tedious for the casual reader. But perhaps there will
be use for these details for others.
rpm -q zlib
zlib-1.1.4-8.1
zlib-1.1.4-8.1
Two of them installed. They look the same. But we can query for more
information and see that they are actually different.
rpm -q --queryformat "%{NAME}-%{VERSION}-%{RELEASE}-%{PLATFORM}\n" zlib
zlib-1.1.4-8.1-i386-redhat-linux-gnu
zlib-1.1.4-8.1-x86_64-redhat-linux-gnu
Let's list the files contained in the package.
rpm -ql zlib
/usr/lib/libz.so.1
/usr/lib/libz.so.1.1.4
/usr/share/doc/zlib-1.1.4
/usr/share/doc/zlib-1.1.4/README
/usr/lib64/libz.so.1
/usr/lib64/libz.so.1.1.4
/usr/share/doc/zlib-1.1.4
/usr/share/doc/zlib-1.1.4/README
That listing lists both packages back to back. Each zlib package has
two parts. One is architecture dependent, the /usr/lib/lib*so* part.
The other is architecture independent, the /usr/share part.
This is where it gets ugly. The /usr/share part overlaps between the
two packages. As long as the md5sum of a file is the same rpm will
allow packages to overlap files. (Personally I think that is a bad
thing and should not have been designed that way.) I used zlib as a
small clean example. Other packages have man pages shared in
/usr/share too and the list goes on.
This file overlap behavior is a base feature of rpm and predates
biarch by a long time. Any two packages can share files if the md5sum
matches. But remove one of the packages and that file is removed,
leaving the other package in a broken state without that particular
file. This has been a long standing behavior of rpm that is now
exploited for use in biarch. Also that you can install multiple
packages of the same name as long as no files with conflicting md5sums
overlap between them. This has been used for a long time to install
multiple versions of shared libraries with exactly the same package
name.
These two biarch packages are almost but not quite required to be in
lockstep. It is possible to upgrade one without the other as long as
the shared files have the same md5sum. But since that rarely happens
in practice it means that you must upgrade both at the same time on
the same command line to rpm. Because if on the same command line
then rpm will allow the upgrade, but not separately.
What uses /usr/lib/libz.so.1, the 32-bit library? Nothing on the
system. That is provided for 32-bit compatibility with other
binaries. The system is otherwise fully 64-bit and will use the
/usr/lib64/libz.so.1, the 64-bit library. This is equivalent, but
different, to a 32-bit chroot on Debian because it has all of the
files in individual packages as the actual 32-bit versions. This is
not the same as ia32-libs which has all of the libs lumped into one
monolithic library package. Of course the effect of being able to run
32-bit legacy programs in compatibility mode is the same.
The native system is fully 64-bit in that all of the /bin and /usr/bin
programs are 64-bit. The shell for #!/bin/sh for example is 64-bits.
The /usr/bin/perl is 64-bit. And so on. I believe all executable
binaries on PATH are 64-bit.
The rpm program knows about architectures for dependencies. But
packages are not always there. For example the ghostscript package
depends upon 'libm.so.6()(64bit)' fine. But only depends upon 'zlib'
and I believe if only the 32-bit version were installed it would meet
the dependency of that particular package but of course not be
sufficient to the needs of the 64-bit program. Of course this is
simply a single package bug but illustrative.
The rpm .spec file that builds the library packages (similar to
debian/rules et al) is the same between 32-bit and 64-bit builds but
produces different locations for the library files. This is done by
using %{_libdir} as a macro in the spec file. That definition is
changed to be /usr/lib on 32-bit compiles and /usr/lib64 on 64-bit
compiles. So the same source builds two different packages. But on
different hosts.
These compilations take place on different machines because it depends
on and uses the default build on that host. Otherwise the .spec file
would need to be different and it is counted on to be the same so it
must use the defaults on the different hosts. To the best of my
knowledge it is not possible to build a normal 32-bit rpm package on a
64-bit host, unless using a 32-bit chroot which of course would work.
Bob
Attachment:
signature.asc
Description: Digital signature