Yesterday, I spent most of the day finishing up the multiarch work I'd been doing on introducing multiarch to the eID middleware, and did another release of the Linux builds. As such, it's now possible to install 32-bit versions of the eID middleware on a 64-bit Linux distribution. For more details, please see the announcement.
Learning how to do multiarch (or biarch, as the case may be) for three
different distribution families has been a, well, learning experience.
Being a Debian Developer, figuring out the technical details for doing
this on Debian and its derivatives wasn't all that hard. You just make
sure the libraries are installed to the multiarch-safe directories
/usr/lib/<gnu arch triplet>), you add some
Multi-Arch: foreign or
Multi-Arch: same headers where appropriate,
and you're done. Of course the devil is in the details (define "where
appropriate"), but all in all it's not that difficult and fairly
The Fedora (and derivatives, like RHEL) approach to biarch is that
64-bit distributions install into
/usr/lib64 and 32-bit distributions
/usr/lib. This goes for any architecture family, not just
the x86 family; the same method works on ppc and ppc64. However, since
fedora doesn't do powerpc anymore, that part is a detail of little
Once that's done,
yum has some heuristics whereby it will prefer
native-architecture versions of binaries when asked, and may install
both the native-architecture and foreign-architecture version of a
particular library package at the same time. Since RPM already has
support for installing multiple versions of the same package on the same
system (a feature that was originally created, AIUI, to support the
installation of multiple kernel versions), that's really all there is to
it. It feels a bit fiddly and somewhat fragile, since there isn't really
a spec and some parts seem fairly undefined, but all in all it seems to
work well enough in practice.
The openSUSE approach is vastly different to the other two. Rather than
installing the foreign-architecture packages natively, as in the Debian
and Fedora approaches, openSUSE wants you to take the native
foo.ix86.rpm package and convert that to a
package. The conversion process filters out non-unique files (only
allows files to remain in the package if they are in library
directories, IIUC), and copes with the lack of license files in
/usr/share/doc by adding a dependency header on the native package.
While the approach works, it feels like unnecessary extra work and
bandwidth to me, and obviously also wouldn't scale beyond biarch.
It also isn't documented very well; when I went to openSUSE IRC channels and started asking questions, the reply was something along the lines of "hand this configuration file to your OBS instance". When I told them I wasn't actually using OBS and had no plans of migrating to it (because my current setup is complex enough as it is, and replacing it would be far too much work for too little gain), it suddenly got eerily quiet.
Eventually I found out that the part of OBS which does the actual build
is a separate codebase, and
integrating just that part into my existing build system was not that
hard to do, even though it doesn't come with a specfile or RPM package
and wants to install files into
/usr/lib. With all that
and some more weirdness I've found in the past few months that I've been
building packages for openSUSE I now have... Ideas(TM) about how
openSUSE does things. That's for another time, though.
(disclaimer: there's a reason why I'm posting this on my personal blog and not on an official website... don't take this as an official statement of any sort!)