Tom Rockwell wrote:

> 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...).

Well yes, it seems to be buggy...
I found many RPMs that failed to install due to conflicts between files
from the i386 RPMs. I also find some curious behavior in the number
of occurences of the RPM for the %post and other scripts.

I also want to test in real case updates, because I suppose that problems
will also arise...

>
> 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 :-(

That's a problem, but it's logical...

>
> 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).

I built a script that installs all libraries from the i386 RPMs that
correspond
to the installed ones of a x86_64 system.
I previously try to install the i386 RPMs over the x86_64 ones, but for a
very large majority of RPMs it failed to install.
And tricks are not easy to use inside automated installations...

My final goal is to make a standard x86_64 installation (kickstart in my
case) and to automatically add all the i386 libraries that correspond to the
installed 64 bits libraries... At this time the given 'rpm' failed to offer
that feature without many additionnal manipulations...

--
Yannick

>
> 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
>