Re: multiarch/bi-arch status (ETA) question
bob@proulx.com (Bob Proulx) writes:
> 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.
That sounds like there is no special biarch support at all in rpm but
just the support to have multiple versions of a package installed and
incidentaly that can be used for this too. Lucky break for rpm I
guess.
This is quite similar to very early biarch proposals.
> 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.
Now that '(64bit)' is something they had to add for biarch support.
There was talk about doing the same for multiarch early on but it
breaks backwards compatibility, i.e. old packages that don't have the
(64bit) will break. We improved that by having libraries state
"Multiarch: yes" and have dpkg then match the arch of the lib and
depending package to see if thats enough.
> 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
That will (at first) be true for multiarch too. Using 'linux32 chroot
somewhere' will work but not just building on the host directly. I'm
not sure if anyone is thinking or working on creating support for
'cross' builds without the chroot. Doesn't seem usefull as all builds
should be done in chroots anyway.
MfG
Goswin
Reply to: