Tag Archives: Fedora

It appears that many of my dependency issues with perl may be the result of sloppy RPM spec files from the Fedora community. No offense intended to them either.

In my RPM bootstrapping of this LFS build, most of the RPM spec files I carefully wrote myself, so any problems with them are purely mine.

With perl, there are just far too many perl modules. I wrote the base perl spec myself but I was not about to write a spec file for each and every perl module that I need, there are literally hundreds of them. So for perl modules, I took source RPMs from Fedora 18.

It appears that many of the BuildRequires in the Fedora spec files are bogus, meaning they are not actually needed to either build the package or run the package test suite.

I apologize to the perl community for coming to the wrong conclusion about this.

I have to tip my hat to the Fedora Python maintainer, looks like it is David Malcolm.

I’m currently running a Linux From Scratch system, and I’m in the process of RPM bootstrapping it. Package management is critically important to a *nix system, too many bad things can happen when you run make install as root.

This LFS system does not yet have Python. A Linux system without Python, I know, crazy. Really though, I did not want to install anything that is not required by RPM untill the system is fully RPM bootstrapped. Furthermore, a complete build of Python requires Tk and that requires various GUI libs. So whatever Python implementation I use will need to be rebuilt later when I have Tk installed, and that’s easiest done with RPM.

My LFS system is not multilib, but I want to leave that possibility open for the future. I personally don’t give a shit about being able to run 32-bit software, but some people might (e.g. for Adobe Reader which is only 32 bit on Linux – open source PDF readers are generally better but some things like PDF forms, Adobe’s version may still be needed) so I have {,/usr}/lib64 as a separate directory from {,/usr}/lib.

In the future I can do a multilib toolchain and all will be groovy.

The Python source however is not multilib ready. 64-bit objects should go in /usr/lib64/python2.7 and components that are common to both 64 and 32 bit systems should go in /usr/lib/python2.7 – but the very complex Python build system doesn’t really support that.

That’s where the Fedora Python spec file comes in to play. I’ll be honest, even though I use to be a packager for Fedora project (volunteer, not paid) – a lot of the Fedora spec files are overly complex with numerous patches. While I’m sure each patch solves a very real problem, sometimes the cause issues too. Like that time my hardware failed and I tried to mount my ext2 filesystem on a different distribution only to find out custom extensions had been patched in for features I didn’t even need that caused the other linux system to not be able to mount my drive.

I don’t remember checking a box that said “Make my filesystems in-compatible with other distributions” when I installed the system. But anyway, my philosophy is to stay as close to pristine upstream source as possible unless I have a damn good reason to deviate. With Python I have a damn good reason to deviate because it installs incorrectly for systems where the rpm macro %{_lib} expands to “lib64” instead of “lib”.

I installed Fedora’s source rpm and dreaded looking at it, but I was pleasantly surprised. Their build of Python is far more complex than I want, patches up the wazoo, but each patch is very well documented where it is defined making it easy for me to find the lib64 related patches and glance at the others, discarding those I don’t want.

Anyway, the Python source rpm is an example of how to properly do a complex spec file. Most spec files are simple (basically just %configure; make; make install DESTDIR=%{buildroot}) but when complex builds are done, often the spec files are really messy – the Python spec file from Fedora is an example of a very complex build that is properly done.