Perret,

Your understanding of this is more advanced than mine, I have just a
single dual-opteron running SL303 x86_64.  I've only done a little bit
of work with 32 bit binaries on this system - the main thing so far was
getting RealPlayer going ;-)  My understanding is that the official way
to install 32 bit libs is to simply install the rpm from the i386
distro.  The 64 bit libraries go into a new directory structure (/lib64)
and 32 bit libraries go into the old library tree (so the i386 rpms
don't need to be modified).  As you noted, the binaries, doc files, etc.
will overlap between the two rpms, however rpm doesn't replace files by
default.

The newer versions of rpm also have some logic to deal with this
situation - it seems that rpm automatically excludes some files when you
install the i386 version of an rpm over an x86_64 install.  Oddly, it
doesn't seem to exclude everything (or this seems buggy...).

For instance, if I try installing openssl i686 rpm (which includes libs,
docs, binaries, config files...) over the x86_64 system, there will be
many files that overlap, however, rpm only complains about 7 (or of
about 40) overlapping man pages.  (It's not clear to me why it cares
about these 7, but not others...)  The openssl i686 rpm will install if
I use the --excludedocs option.

After installing the i686 openssl rpm, the file /usr/bin/openssl is
unchanged.  Doing "rpm -qf /usr/bin/openssl" gives:

openssl-0.9.7a-33.12
openssl-0.9.7a-33.12

So, both rpms are claiming ownership :-(

To remove the i686 rpm use the command, "rpm -e
openssl-0.9.7a-33.12.i686".  The overlapping files don't get removed by
this command.

Yum is supposed to have some logic for x86_64 now as well.  I didn't see
your earlier message, did you have issues with using rpm instead of
copying the libs by hand?  It seems the "official" way of installing
i386 rpms works (with some hitches).

Cheers,
Tom

(I added additional comments below...)

Perret Yannick wrote:

> Hello,
>
> some times ago I sent a little script that extracts and installs
> i386 libs to provide i386 compatibility on x86_64 systems.
>
> I have installed a set of 32 i386 machines (dual opterons) which
> are used in production in our farm.
> I also installed an additionnal machine in x86_64 with the
> full i386 libraries.
>
> Here is some notes about that, if other people wanted to do the
> same :
>
> First, many RPMs only provides libraries, not symlinks. And in
> some cases it is not always possible to guess what symlinks
> should be created. It is so difficult to make a full automatic
> process for that. I had to do some minor job by the hand.

These symlinks are normally established by ldconfig.  Rpms that install
libraries will normally run ldconfig in postinstall and postuninstall
scripts.

>
> Second, some x86_64 RPMs do not exists in the i386 repository,
> or with a different version number. You have to make the choice
> to ignore it or install the older/newer one. Please remember that
> only libs should be installed. No executable/config file sould
> be copied, as they would overwrite existing ones (from the x86_64
> installation).
>
> Third, be sure to add the new library pathes (i386) in /etc/ld.so.conf
> so that all will be found be the dynamic linker (in particular 32 bits
> versions of X11 libraries).

The i386 version of XFree86-libs does this in the postinstall script.

>
> Fourth, do not forget the x86_64 package for i386 libs (something
> like *32*.x86_64.rpm), which gives the glibc).
>
>
> At last, I get a 64 bits system with the full set of 32 bits libraries.
> I added it in the production farm, and jobs run without any problems.
> By the way we use openAFS, and of course the sysname for the 64 bits
> machine is the same than for the 32 bits machines.
>
>
> So the conclusions :
> - it is possible to have a 64 bits system (for performance reasons) with
> a full 32 bits set of libs (for compatibility). At this time we do not
> met
> any problems (but it is for batch, not for interactive machines... users
> can be _very_ more inventive and discover bugs...)
> - installing the 32 bits libraries "by the hand" is not a good thing for
> several reasons:
>   - it is complicated
>   - we can miss some things which are done in the post-installation
> scripts
>   - we do not have a way to manage updates properly
>
> For the first point it is a good thing, because we can have a smooth
> evolution between 32 bits and 64 bits systems.
>
> For the second point, the only way should be to use 'rpm' to handle the
> i386 RPMs in the same way than the x64_64 ones.
> I think I will have a look to the current 'rpm' sources to see if this
> can
> be integrated...
>
> Regards,
> --
> Yannick Perret