APM: Bugzilla, Perl, server

[Montgomery Conner]

I'm getting the impression that what you really need from Perl is just
*dependency
support for a single application*: Bugzilla... and that this particular
dependency *happens* to be Perl is more-or-less irrelevant. Is that correct?

I hate to ask the obvious, but did you RTFM for Bugzilla?

I took a quick look and found pertinent documentation about custom
installations such as the one you're attempting here:
http://www.bugzilla.org/docs/3.6/en/html/nonroot.html.

But this really begs the question: If your real need is specifically
Bugzilla why don't you simply install an RPM for that software and let it
handle it's own dependencies? If it doesn't handle it's own dependencies
correctly file a bug ( oh, wait... ;-) ) ... and if there isn't an RPM of a
recent enough version of this software available it sounds more like an
issue for your OS vendor than Perl.

I understand that you're frustrated, but in retrospect I guess I just don't
understand the point of all your initial questions about Perl in this
context... but maybe I'm missing something.

Perl is really just an incidental detail here of the complexity your
encountering with a large and proportionately complex piece of *totally
unrelated* software... It's like complaining to Sun MicroSystems that you
found a big FOSS Java application online that you can't get to work...  :-S

Issues like this might more productively be directed to specific project
mailing lists... for example, Bugzilla's mailing list.


Sorry,
m


On Thu, Apr 15, 2010 at 4:44 PM, Tim McDaniel <tmcd at panix.com> wrote:

> 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
> _______________________________________________
> Austin mailing list
> Austin at pm.org
> http://mail.pm.org/mailman/listinfo/austin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/austin/attachments/20100415/faab7afd/attachment.html>