[Clfs-support] CLFS RPM project

Michael A. Peters mpeters at mac.com
Fri Sep 26 22:30:41 PDT 2008


RPM CLFS project

Just thought I'd share with the list what I'm currently working on.
I'm working on RPM boot strapping both i386 and x86_64 builds of CLFS.

Initially I was working with multiarch but that was the wrong approach, 
the goal is to end up with a set of i386 and x86_64 RPMs that can be 
used in a yum package repository for building additional software in 
mock. Mock is a chroot build tool that assists in the creation of 
pristine packages that do not link against what you do not specifically 
want them to link against, and that can be important in long term system 
maintenance.

The problem with using multilib was glibc and gcc - I could build i386 
packages that in most cases were just dandy, but the resulting i686 
glibc packages were not equivalent to x86_64, and gcc - it would build 
both 32-bit and 64-bit from the single make command when multiarch is 
not disabled in its configure, and that's just not suitable for 
producing pristine i386 and x86_64 packages.

My new approach is "pure" 32 bit almost identical to the CLFS book and a 
"pure" 64-bit with some multiarch book patches so that it properly use 
lib64 and will allow for the eventual installation of 32-bit RPMs.

I may not end up with a multiarch C compiler, I don't know enough about 
gcc to know if disabling multiarch at configure but installing the 
32-bit libraries will allow 32-bit compilation from 64 bit Linux, but I 
should at least be able to run 32-bit libraries and programs inside 
64-bit Linux. I really only need that for a handful of programs (IE 
google earth, Adobe Flash, and 32-bit TeX Live - I suppose I could use 
64-bit TeX Live but hear 32-bit is far more stable, or at least was a 
few years ago).

Most of the RPM packages I am writing from scratch, as close to the 
CLFS/CBLFS build instructions as I can stay. There are a few minor 
deviations, IE using /etc/ld.so.conf.d/ is so much easier for RPM than a 
single file. Generally with RPMs that result in both binaries and 
libraries, I'm putting the libs in a sub package so that it's easier to 
install the 32-bit version in 64-bit. RPM allegedly does decent job of 
handling that, when both arches own a file the 64-bit take priority, but 
I think it is cleaner to just not have it an issue. I'm also using 
rpmlint to verify the integrity of the packaging as much as possible.

perl - I am deviating from the CLFS perl instructions, so that there is 
a common place for 32-bit and 64-bit to look for non arch specific perl 
modules. The 32-bit is almost the same but 64-bit has some extra args to 
make it look in the same place that 32-bit perl puts noarch stuff. I may 
need to do the same for Python and Ruby but I haven't looked into them yet.

Anyway - it's a blast, and I'm learning a lot - I'm doing this for me, 
but if anyone else is interested I'd love to share. I'm not sharing any 
packages, but rpm spec files for packages I can share. I may try to put 
together a tips page for installing rpm itself - it's not *too* hard, 
but if you want debug package support you need elfutils and it seems the 
newer versions of elfutils depend upon patches to the fedora/redhat 
toolchain (compilation ends up stuck in what appears to be a loop with 
cc1 taking 100% of the CPU and never finishing the task it gets stuck 
in) - but I found a version that both builds and isn't too old for 
modern RPM. I don't think I'll be ready to share anything for a few 
weeks though, I highly suspect I'll fubar the system a few times before 
I get things right - I already did once with glibc ... (that seems to be 
resolved now)

I've almost got the i386 build bootstrapped, then it's time to test the 
spec files on 64-bit ... and then get mock installed and working.



More information about the Clfs-support mailing list