# An observation on the quality of the Perl build in Ubuntu 9.04

I have long ago given up on the perl builds in Redhat and build-alikes. To call them broken is … well … to be unfair to things that are merely broken. The Redhat/Centos Perls are basically completely hosed, in part due to incorporating bad patch mixes, poor build Config options, etc.
Some will claim that despite the broken-ness of the build, it is better to stick with this build, and not install updated/corrected modules via CPAN.
That is incorrect, at many levels. The most obvious is that if the OS packaging system isn’t up to the task of handling installed modules through the correct and standard perl module installation system, developers and users of those modules shouldn’t have to suffer while waiting for a blessed package (built correctly at that) to appear.
But that has been Redhat and Centos, which uses the Redhat build.

For a long time, Ubuntu had been better. Things that should work, mostly, work. Correctly.
Occasionally we run into build issues.
Well, they have been getting progressively worse since 8.04 Ubuntu.
8.10 Perl was barely functional.
I can report that 9.04 is not suitable for running for most applications.
We have our own build environment for Perl. We haul it out when we need things built correctly, and the native install doesn’t quite do it.
Packaging is via tarball. We put it in a completely different path, just in case some critical functionality in the OS is built upon the broken behavior.
Ok, what do I mean by broken?
Say you are installing a development environment. Like Jifty. Or Catalyst.
Each of these have huge dependency radii. They depend upon an astounding number of modules.
Which makes them fairly sensitive to the quality of the underlying build.
So now install the modules. As Jifty installs, you will see astounding numbers of build failures along the way.
Do the same thing with Catalyst. Previous version, as the 5.8 release appears to have a bug with Perl 5.10, and they call it out during build. Perl 5.10.1 has the fix. Hopefully out soon. Info on the bug is here http://rt.perl.org/rt3/Public/Bug/Display.html?id=49472 . This was a real bug with Perl itself, not any build of Perl.
Then go into each of the failed directories and issue the
 make clean perl Makefile.PL make make test
And notice that you don’t have failures.
Then you can make install.
For a long time we used our own build, then we started trusting the Ubuntu builds when they did the right thing. They no longer do. We don’t trust the RH builds.
So I think we are done dealing with these issues. Just use our own build. This way, we know it works. No messing around dealing with distro specific self-imposed issues.

### 9 thoughts on “An observation on the quality of the Perl build in Ubuntu 9.04”

1. Some 6 month ago I needed some Python based math and plotting sw. It took me 2h to install on Windows, some 2 days on Fedora 6. On Windows the installers simply install all what is needed (like GTK, Qt) into a dedicated dir-tree. With disk-space so affordable I wish that there were more all-inclusive Linux installers like those on win32/64.

I think the issue isn’t the installer. Its that Windows doesn’t ship with any tools, so the people who package them, figure that they have to install everything. In Linux, some of the tools are installed. But the quality of the tool builds are lacking in many cases.
What we do is akin to your full on installer. Assume the hosts tools are borked, and simply install working tools elsewhere. Don’t try to fix the borked tools, don’t try to replace them. Install tools elsewhere.
Another “favorite” of mine is eclipse. Eclipse is an IDE, unfortunately written in Java, which means it is slow on every platform and hogs memory, but with support and plugins for Perl, Fortran, C/C++, debuggers, make, etc. It could be a good thing for users.
Except that every distribution packages it slightly differently. And the packaging is such that it, again, precludes you from using useful features. Like some of the plugins.
I have noticed this in the past with apache. In the 1.3.x days, the distributions tried “adding value” with their apache packaging models. All of which only managed to break something critical. Usually with a comment in mail lists that we shouldn’t be trying to use that feature anyway, because they didn’t like it, or didn’t think it was useful.
With Apache 2.2, it looks like the distros have given up “adding value”. Which means, thankfully, that things work the way they are supposed to.
Now only if we could get people who use the packages, and know what should be in them, and how they should be built, to act as the builders of the packages. In many distros, it looks like one person builds many (or in some cases, all) the packages, and is more interested in the care and feeding of their package build system than the package themselves.
Which is, I think, the reason why I have things to complain about relative to the package builds.

3. May be you should consider switching to Gentoo. In this case, that would help. Generally too, I find that sometimes you need the flexibility of of doing the package compilation/building yourself. This does not happen often, and I do not know enough to make use of it all the time, but still, I feel Gentoo is a great way to go. {{{OK, OK, KDE, openofffice compilation would suck, I agree}}}. But perhaps, a live cd install won’t be a problem.

4. @Rohit
Tried Gentoo. Didn’t like it. I find it simpler to remove or ignore packages I need to rebuild than to rebuild the whole distribution. Some people like it, more power to them.
Gentoo has though, IMO, the *best* documentation, second to none, in the Linux world.
I can often find questions I need answered there. Where they aren’t anywhere else.

5. May be one one day you would just do make -j16 (hardware threads, 8 real cores) and compilation would be almost as fast as downloading 500MB -1GB packages. :/
BTW, is there any way that follow up comments are auto-mailed to the commenter?

6. @Rohit
On the followup comments, I let anyone (human) respond to a comment. The danger in doing an auto-mailed response is that this is trivially abusable for spam purposes. I do try to prevent spam on the site, and want to minimize spam generation from the site.
I’ll look into this, see if I can do this for logged in users. But given the sheer volume of fake accounts I see being attempted to be set up, I am reluctant to go even there.

7. this is a test of the comment bits …

8. and again …