APM: Bugzilla, Perl, server

Tim McDaniel tmcd at panix.com
Thu Apr 15 14:44:39 PDT 2010


My technical lead is getting immensely frustrated right out of the
gate, for the same reasons that were frustrating me.

We are looking into installing a late-model Bugzilla on "Red Hat
Enterprise Linux Server release 5.3 (Tikanga)".  The system will run a
few other related programs, like source control and such.  Bugzilla is
written in Perl (et cetera) and has module dependencies, many of which
are not distributed with Perl.

There are all sorts of pages with advice like "on a server, always
build and maintain your own Perl in a side directory", and "never use
CPAN on a system perl where modules are installed by a package
manager".

So far as I see it, this all makes it a pain in the butt to someone
who just wants to install one damned application and use it, and
before this my technical lead didn't like Perl anyway.  These are the
issues I saw:

- You should run "perl -V" to get all the compilation options on the
   system perl (as a hint as to useful or expected features), and use
   those options on your private Perl, except that in this case the
   system perl is 5.8.8 and the almost latest perl is 5.10.1, so I
   don't know that the options are compatible.
   It seemed a minor pain to specify the side directory and to be sure
   that it was always being used.

- All the Bugzilla Perl scripts start "#! /usr/bin/perl", so you have
   to stomp on the system perl anyway, or edit every script's top line,
   and then try to find if any file invokes perl on its own.

- To make it possible to unstomp, you have to research and set up
   /etc/alternatives.  In my little bit of looking at
   /etc/alternatives, it seemed that there are a LOT of slave programs
   for perl and a lot of complication in it.

Anyone with experience in Bugzilla, Perl, and Perl maintenance on a
server?

-- 
Tim McDaniel, tmcd at panix.com


More information about the Austin mailing list