The Problems of Perl: The Future of Bugzilla

[Aaron Trevena]

On 15/05/07, Gervase Markham <gerv at mozilla.org> wrote:
> Aaron Trevena wrote:
> > I think I have the contacts although I think a couple of the bugzilla
> > people have burnt some bridges with some of the trolling on the wiki..
> > Randal was only half joking when he said  ""We'd actually prefer you
> > stop using Perl. You seem to be giving it a bad name. KTHX, Bye".
>
> I missed all this wiki stuff... I had no idea that we'd had some sort of
> flame war.
>
> Maybe everyone needs to just take a week off, cool down, we can pretend
> this all never happened, and start again with a clean slate?

I've cooled down now. I first donned my asbestos typing gloves on bbs
and mailing lists a dozen or so years ago.. heck I even managed to
work with somebody who responded with his fists to something I said
when I was treasurer or our uni computing society.. perhaps our
sailing trip had an alterior motive beyond pretending to be members of
sailing soc in order to blag a dinghy for the afternoon and getting
towed back from the rip  by Drake Island saved me from davey jones
locker..

> > Something that Bugzilla could do for the perl community is to work
> > together to find the best solution for packaging CPAN modules into a
> > standalone application - the catalyst people have been working hard on
> > making CPAN dependancies less of an obstacle for installation, and PAR
> > could certainly be a solution for Bugzilla.
>
> Are they an obstacle even on Unix?
>
> I've never had much problem with them recently, but then maybe I've done it quite a
> few times. Wasn't Bundle:: invented to solve this?

Apparently so.

Debian/redhat perl packages can be out of date (sometimes by years) or
just plain broken or configured by crack monkeys, or can clash with
cpan modules so you have multiple versions, etc (I don't think this is
unique to perl packaging - distro package quality varies wildly
accross all software on all distributions).

Large numbers of dependancies can be problematic - a test could fail
for some reason high up in the dependancy chain breaking automatic
installation for everything relying on it, some crypto modules won't
install without you specifying which particular obscure implementation
of an encryption algorithm you haven't heard of, etc.

Of course some users don't have the knowhow to use CPAN - there is no
technical reason not to use it anywhere with an internet connection,
only lack of awareness of it, or how to use it as a non-root user, or
issues with policies on installing software.

That doesn't mean you shouldn't use CPAN modules - it just means you
need to make it your problem rather than the users to install the
right software - you can bundle dependancies along with the package
and only install them if they aren't already installed or are newer
than those installed - makefiles can handle this fairly well, you can
also use PAR, and or create a custom linux package that provides the
required stuff.

Making Perl applications installable easily for people who don't know
unix or perl well is something a chunk of perl community is interested
in, as it would increase deployment of frameworks like Catalyst and
applications built on them.

It could also make life easier for those of us that develop bespoke
systems to deploy and change control our software.

.. for example currently I'm building debian packages of about 30,000
LoC (according to sllocount, and excluding dependancies) and will be
deploying that to staging, test and production servers in stages over
the next few weeks and months. I'm prototyping an automated system
using cpanplus::dist and dpkg::parser at the moment.

Cheers,

A.

-- 
http://www.aarontrevena.co.uk
LAMP System Integration, Development and Hosting