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
signature.asc
Description: Digital signature