[cmake-developers] Help requested for running CPackRPM tests on SLES 10 machine

[Eric Noulard]

2011/3/13 Rolf Eike Beer <eike at sf-mail.de>:
> Am Sonntag 13 März 2011, 21:19:41 schrieb Eric Noulard:
>> 2011/3/13 Eric Noulard <eric.noulard at gmail.com>:
>> > I'll try to [blindly] fix this with a SUSE specific test *in the test
>> > itself* and not in CPack RPM.
>>
>> I did push forward the stage "CPackRPM-TestWithMoreTraces" and merge it to
>> next. This last commit should make the CPackRPM test work on SUSE 64bits.
>>
>> Would you be able to re-try for me using next?
>
> http://www.cdash.org/CDash/buildSummary.php?buildid=902959

Ok this is re-assuring.

> I hope that there will be a way to detect and honor this lib/lib64 policy
> thing on a general base and to handle that properly in normal installs and
> RPMs.

The thing is, I'll have to check how the different distributions
handle this case,
for example on my Debian 64 bits box I have:

$ ls -ld /usr/lib*
drwxr-xr-x 311 root root 151552 12 mars  23:30 /usr/lib
drwxr-xr-x  33 root root  45056 29 janv. 10:18 /usr/lib32
lrwxrwxrwx   1 root root      3 31 déc.   2008 /usr/lib64 -> lib
drwxr-xr-x   3 root root   4096  1 janv.  2009 /usr/libexec

As you can see /usr/lib is the 'native' lib dir, with lib64 being a
link to this.
Then lib32 is the 32bits 'non-native' one.
This layout seems reasonable, I'll check on Fedora 64 or other RPM based
distros during this week.

Now I may teach CPackRPM to detect if it is running on Fedora or SUSE
or Mandriva etc..
and do some nasty things like renaming lib destination into lib64
if we are packaging a 64 bit package but I currently find it weird.

The rpm installer (the rpm command) or  packager (rpmbuild) perfectly knows
that we are building a natively 64 bits RPM package it's even written in the RPM
using "Architecture" field so if he wants to enforce to put 64 bits
libs into lib64
he may do it by itself and not asking the packager to do it.

Currently I would say that rpm build policy on SUSE 64 bits
is the culprit not CPackRPM (which is simply calling RPM build).

However, I'll investage further because up to now I did never face
such 32/64 bits issue
even if I use natively 64 bits linux systems since at least 5 years...

Slackware seems to be using lib${LIBDIRSUFFIX}
http://www.mail-archive.com/slackbuilds-users@slackbuilds.org/msg01569.html

Others (like at least Fedora, RedHat, Mandriva)
seems to be using builtin RPM "%_libdir" macros.

The thing is currently with cpack the user chose the library/runtime
destination
so if he chose 'lib' shall we go with "lib64" should be safe but
if the installation prefix is not '/usr' but '/opt/' or '/anywhere/you/want'
shall we do the lib-->lib64 automatic renaming.

Any insight or reference about this 32/64 bits lib mixup is welcomed.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org