People Hate Perl

People Hate Perl – OK, not a blog about php, but 😉

Perl is a scripting language originally written by Larry Wall and still maintained by him, though at this point it has thousands of developers all around the world, just like virtually any successful FLOSS project.

It is a critical component of virtually and GNU operating system, the autoconf tool that is at the heart of virtually every portable code project relies upon Perl.

I hate it. It isn’t so much the language itself that I hate, it’s the damn CPAN bloated module infrastructure that I hate. Virtually every little function is it’s own module that depends upon other modules that depend upon other modules and so on.

The model that the Perl developers have is that you use their cpan tool to install what you need and it grabs everything and manages for you. Unfortunately that model does not work well with a modern FLOSS operating system, one of the advantages of a FLOSS operating system is you can have universal package management that takes care of things like automated dependency resolution. Installing perl modules via the cpan binary, the package manager does not know about them. For cpan modules with binary dependencies, cpan requires that you have the binary dependency including its header files already installed or it can’t build you the module.

This blog is about the extent of the dependency bloat the Perl has. It’s really bad.

Right now I am working on building my own Linux distribution. I like CentOS but a lot of the software in CentOS is rather dated. That’s fine for servers, but not for the desktop. Fedora on the other hand does a lot of things in a way I really don’t like, especially GNOME 3. I could blog forever about my gripes with GNOME3 – the list is very long.

The source is open though, so use it, damnit. I’m currently building my own distribution for the purpose of doing things the way I think they ought to be done. Perl is an essential part of any Linux system, hate it or not you gotta have it. While the vast majority of my RPMs I am writing from scratch, there are just too many perl modules. I certainly do not need them all, but Perl likes to have a dozen plus different modules for the same functionallity that is often within a single library binary library package in C/C++ land.

So I am doing perl in a way that allows me to just take Fedora perl module source RPMs and rebuild them in YellowJacket GNU/Linux. My layout is a bit different, I but binary modules in /usr/lib{32,64}/perl5 and noarch modules in /usr/lib/perl5. Fedora just uses /usr/lib for 32-bit libraries, they don’t have a /usr/lib32, so it puts binary modules in /usr/lib{,64}/perl5 and noarch modules in /usr/share/perl5 – but the different layout is handled automagically by macros in the RPM spec file at build time.

My spec file for perl results in a total of 65 packages (originally 66, soon 66 again), it has to be split up into that many packages because some of the modules have necessary updates that in CPAN and need to upgrade the module as it was distributed in the perl tarball.

Most source tarballs when compiled and packaged in an RPM result in 2 or 3 packages. one for the executables, one for development files (headers and such), and if it has shared libraries, one for the shared libraries.

My system was just about finished being RPM bootstrapped, meaning it was a minimal system where every piece of software installed from source had been replaced by packaged RPM versions of the software. OpenSSL was all that was left. At that time, there were 65 perl RPMs installed from the single source perl RPM.

OpenSSL installed a script that required the perl(WWW::Curl) module, a module not provided by the core perl system.

Building that module requires the perl(Test::Base) module to test the build of the module. It is very important to run the test suite, if there is a problem in the package, finding it by running the test suite can save you a lot of headaches.

Building perl(Test::Base) required a several other modules, which in turn required several other modules, which in turn required several other modules, and so on.

Right now, looking in my SRPM directory for perm modules I have built in pursuit of getting perl(Test::Base) so that I can build perl(WWW::Curl) there are currently 114 different source RPMs. One hundred and fucking fourteen.

Some of that may be Fedora’s fault. For example, one perl module wanted the Valgrind perl module to build for its test suite. My system is not yet ready for Valgrind, Valgrind has special instructions on how certain libraries are to be stripped, and to be honest, I’m not really that worried about every having Valgrind installed. I know in that particular case, Valgrind really wasn’t necessary for the test suite, so I modified the spec file to not require it. But most of the dependencies are in fact genuine.

In fairness, a users system won’t need all those modules installed to use perl(WWW::Curl), quite a few of those modules (I’m guessing more than half) are only needed to benefit the automated testing of the module after it is built. But it still is fucking way too much.

In the rest of the software world, something like Dejagnu is used for the test suite. Dejagnu requires Expect which requires Tcl. That’s two dependencies the test suite has. Perl on the other hand doesn’t seem to have any kind of standardized test suite, the Perl developers need to write one.

Perl needs a standardized test suite in a single tarball and perl modules that need something else for the test better have a damn good reason to do so.

And enough of this 20 different but closely related modules. That’s just bull shit.

Perl gurus pride themselves on their perl one-liners, how compactly they can do something with Perl. They need to apply that same philosophy to CPAN because right now it is a big fucking bloated mess. The result, I really hate perl.

I guess on the bright side, having built and installed that many modules going through the test process for each one successfully, I guess it’s a good indication my Perl install is working properly…


Fedora has a really nice Python spec file

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.

So thank you to David Malcolm (or whoever maintains it)