Releasing Bugzilla to CPAN

Gabor Szabo szabgab at
Tue Mar 30 15:56:02 UTC 2010

On Sun, Mar 28, 2010 at 1:40 AM, Max Kanat-Alexander
<mkanat at> wrote:
> On 03/27/2010 01:37 AM, Gabor Szabo wrote:
>> did I misunderstand your comment from a few weeks ago
>> and you are actually vehemently against uploading Bugzilla to CPAN?
>        No, not at all. :-) (FWIW, I'm not "vehement" about any method of
> installation or distribution--that would imply an emotional involvement
> instead of a technical consideration,

Sorry, I keep forgetting I am the only one who is emotionally involved in the
open source projects he is working on. Others are in it only for the money. ;-)

>> So let's discuss this. What does the Bugzilla installation process do that is
>> not available in the current CPAN toolchain? Answering this question might not
>> be easy as I don't know what does the Bugzilla installation process do and
>> you don't know what the CPAN toolchain does.
>        Hmm. I think the primary issue isn't about what does that
> CPAN doesn't. We've (or at least, I've) learned over time from the
> differences in the Debian and Red Hat packaging methods that it's
> probably better to leave post-install configuration (like setting up the
> database and so forth) to Bugzilla itself, and packages should just do
> the actual *installation*--that is, putting files where they belong, and
> so forth.
>        The problem is that although there's always a standard place for *Perl
> libraries* that CPAN knows about, and a standard place for binaries in
> the Filesystem Hierarchy Standard, there is no standard, widely-adopted
> location for web applications to go. Also, some (actually, a surprising
> number of) people want to install multiple copies of Bugzilla on the
> same server, which would involve each copy having its own Bugzilla/
> libraries. Yes, people could install the first one from CPAN and the
> second from the tarball, but then that might get confusing because the
> *binaries* would be global, and typing "" would do
> something different than typing "./".

I guess if someone wants to install multiple versions of Bugzilla she already
needs to know a bit more than just blindly follow the instructions.
BTW I think I'd recommend running "perl" and not
"./" as the former also works on windows and AFAIK the latter not.

With Padre we make sure all the extra files (e.g. translation files,
templates etc)
are installed in the share/ directory and then we use File::ShareDir to locate
those files during run-time.

    my $share_dir = File::ShareDir::dist_dir('Padre');

The installation is very simple, we call install_share; (or actually
nowdays install_share_with_mofiles;)
that installs everything that is in the ./share/ directory of the distribution.

>        With the tarball, you just untar it in a directory and that *is*
> Bugzilla. There's no compilation, no actual installation of the
> files--that's just it. And for web applications, as far as I know,
> that's pretty much the standard, unless they're FCGI apps running from a
> single binary (which Bugzilla isn't).
>        There's also a somewhat-significant issue with Bugzilla itself, which
> is the bz_locations subroutine in Bugzilla::Constants. The CPAN
> installer might have to make some manual changes to that, but I think
> you and I are both familiar with how terrible it is when CPAN installers
> make manual changes to files (because then things break and go bad when
> people move files around, not to mention a host of other strange problems).

We could modify the perl Makefile.PL process to ask the user for the target
directory where she wants to install the files and copy all the files there
instead of some directory in @INC.

>> If after a few week or months you don't see progress you can delete it from CPAN
>> and it will be gone. No old unsupported version available from CPAN.
>        That's true, so that might be a reasonable compromise. :-)
>        Perhaps you should upload it with your Makefile.PL and changes
> yourself, after we talk about it a bit just to confirm how things are
> going to go. I don't yet want the Makefile.PL in normal Bugzilla
> tarballs--it will confuse people who are trying to install Bugzilla, and
> installing Bugzilla is hard enough already without any additional confusion.

I don't think that would be a good strategy for several reasons.
One of them is that would mean I start to maintain a privately
maintained fork of
Bugzilla. Even with the fairly minimal changes it would still be a fork.
Not something I'd like to do.
The other one is that my whole point of action here is not only to get
Bugzilla on CPAN
but to get it done so by the core Bugzilla team.
I know this might be some change in the way you work with Bugzilla but
maybe it will
actually help you get some more Perl developers on the team.

BTW, You know you can exclude the Makefile.PL from the tarball
generated by your script...

... but I hear that you do actually feel that installing Bugzilla is hard.

Maybe put out a call on the blog - have you already added the Bugzilla
blog to the Perl blog aggregators? -
to get some help making the Bugzilla installation simpler. There might
be some people out there
who would want to help with that.


More information about the developers mailing list