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.

Advertisements

5 responses to “Perl – An Apology and a retraction

  1. LJ

    > With perl, there are just far too many perl modules.

    Devo said it best, many years ago:

    Freedom of choice, that’s what you got.
    Freedom from choice, that’s what you want.

    • Well, some of the modules are very closely related and really could be put into the same source tarball, as it doesn’t really make sense to have them without each other.

      When using yum on a fedora system (yum provides, yum update, etc.) and it has to download the headers, it can take a little while just because of the sheer number of packages – having 6 different RPMs for modules that really could be in a single RPM from a single source tarball, maybe in the grand scheme of things it doesn’t make a difference, but I think there could be some adjustments made to how perl modules are grouped in CPAN.

      But that’s minor. The dependency bloat I complained about is looking like a Fedora thing, some packagers using BuildRequires (and possibly explicit Requires) that aren’t real.

      • LJ

        You’re not wrong. I just find it interesting that one of the great strengths of Perl- CPAN – which enables anybody to share software – is an object of complaint.

        What I find most interesting about CPAN abundance, is that if there are several modules that solve the same problem, they often solve it in very different ways, and to me that means that one of them might solve it in a way that I would have solved it if I had to write it myself, and the way I like it solved might not be the way you like it solved. So for an investment of an hour of research, I save days of coding and testing, and I find the implementation that *feels right* to me.

        I understand the desire to use RPM (et. al.) to manage dependencies. That’s what cpan clients to for Perl.
        It would be wonderful if cpan clients could get smart enough to use OS-level package managers to insure that prerequisites are installed, and it would be pretty awesome if those package managers would learn how to interact with CPAN to let CPAN manage Perl.

        What we have at present, is a situation where deployment/production support people want to dictate software development practice (“stop reusing code, it’s too messy and makes work for us”), because they have a pre-made solution to deployment, which means they don’t have to give it any consideration. It’s all about what’s easiest for them only. This is very similar to organizations who say that you can only use the version of perl that ships with the operating system, because they don’t want to have to expend effort (and budget) on other people’s stuff. [but I’m not bitter]. [and yes, I am apparently expected to turn my web app into an RPM so it can be lobbed over the wall for deployment by people whose job does not involve supporting the app, but just installing it – but I’m not bitter.]

      • I’m kind of a hypocrite because non-binary PEAR packages I manage with PEAR, not RPM (but binary PECL modules I do prefer RPM) and TeXLive – I install from tug.org and don’t use RPM – I manage it via tlmgr.

        But neither php nor texlive are used by other applications the way perl is. TeXLive is sometimes used to build documentation, but that’s about it. php – there is a cli binary but it’s pretty much only used for cgi stuff, you can write stuff in it for non web services but there are better languages for OS level scripting (such as perl and python) – so having what is provided by php-pear packages and TeXLive packages known to RPM isn’t quite as important.

  2. Max Lybbert

    In this particular case, the RPM was wrong about this particular dependency. Your larger complaint about developers failing to keep a handle on their dependencies is perfectly valid; it’s just not Perl-specific.

    The problem of ever-growing dependencies will only get worse until it becomes common to refuse to install things simply because the list of dependencies is too long (and that is a perfectly valid approach; *often* a long list of dependencies is really a symptom of not using a platform’s strengths).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: