APM: Bugzilla, Perl, server

jameschoate at austin.rr.com jameschoate at austin.rr.com
Fri Apr 16 09:09:26 PDT 2010


---- Tim McDaniel <tmcd at panix.com> wrote: 

> 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:

But you're not installing one damn application..."few other related programs".

> - 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.

Do you have to have a private Perl? Is there some application dependency that prevents them all from using the latest version? My first goal would be to reduce the grunt work I would have to do maintaining it, and that would be reduce the component count.

Have you thought of either a chroot jail or virtualization?

> - 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.

grep, sed, Perl, etc. This is an automation problem involving pattern matching and replacement. I certainly hope you're not implying you're searching that pile of crap with the mk 1 eyeball...

> - 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.

Seems to me some aliases in the appropriate user account might help resolve some of this.

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

Yes, when I used to work at the IBM LTC, but we ran it on its own box.

My fundamental observation is that you're seeing these as problems instead of opportunities to hack the system you 'own'.

--
 -- -- -- --
Venimus, Vidimus, Dolavimus

jameschoate at austin.rr.com
james.choate at g.austincc.edu
james.choate at twcable.com
h: 512-657-1279
w: 512-845-8989
www.ssz.com
http://www.twine.com/twine/1128gqhxn-dwr/solar-soyuz-zaibatsu
http://www.twine.com/twine/1178v3j0v-76w/confusion-research-center

Adapt, Adopt, Improvise
 -- -- -- --


More information about the Austin mailing list