Perl – An Apology and a retraction

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.

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…