Releasing Bugzilla to CPAN

[Max Kanat-Alexander]

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, and installation distribution are
pretty much entirely about technical considerations, mostly about what's
easiest and best for our users.)

	To clarify what I think about the subject, I responded to your comment
on the CPAN-distribution bug:

	https://bugzilla.mozilla.org/show_bug.cgi?id=555181#c6

> Based on the comments on the blog entry and my discussion with others
> it seems that people would be happy to see Bugzilla on CPAN. By making this
> move it will push the CPAN toolchain to fill any hole it might have that the
> current packaging and installation system of Bugzilla fills.

	That'd be cool. :-)

> 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 checksetup.pl 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 "checksetup.pl" would do
something different than typing "./checksetup.pl".

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

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

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.