397432 - Create a PAR::Repository called par.bugzilla.org

Status: RESOLVED WONTFIX

(Bugzilla :: bugzilla.org, enhancement, P4)

Description

[Max Kanat-Alexander]

This is the first step for having Bugzilla use PAR.

Instead of shipping PAR files in the Bugzilla tarball itself, I'm going to create a system called par.bugzilla.org, which will hold a PAR repository for every shipped version of Bugzilla. This way, if we ship some bad version of some dependency, it's easy enough to put a new version in the PAR repository and tell people to run checksetup again (or however that will work, I haven't decided yet). If we shipped the PAR with the Bugzilla tarball, it would be a lot more difficult.

So, for example, the first PAR repository available will be par.bugzilla.org/3.1.2+/ for Bugzilla 3.1.2+. I can probably symlink all future versions to it, easily enough. When we need to create a whole new repository, we can do that fairly easily, thanks to the script that Steffen gave us that creates PARs for all Bugzilla deps.

Comment 1

[Max Kanat-Alexander]

Okay, this is up at http://landfill.bugzilla.org/par/ now.

I'm not sure it's perfect yet, we'll have to fix that.

Also, as a note to myself here (and an explanation for any future maintainers) we have to ship two versions of Template-Toolkit--one with the XS Stash and one without. That is, one that's a pure-perl version, and one that has XS in it. So that's one module we'll have to compile separately.

Also, we can't really reliably ship the GD module, because it has a dependency against the particular version of libgd that it was compiled against. So that's one thing that people are still going to have to install themselves or from CPAN.

mod_perl2 also won't be shipped--that requires configuration of the local Apache.

There's several modules that show up in optional_binary when I create the dependencies. I have no idea *what* requires each of these particular modules, because they're not direct dependencies of Bugzilla, except HTML::Parser.

Here's the optional binary modules that I don't know anything about:

Compress-Raw-Zlib-2.006-i386-linux-thread-multi-5.8.5.par
Crypt-SSLeay-0.57-i386-linux-thread-multi-5.8.5.par
Digest-SHA1-2.11-i386-linux-thread-multi-5.8.5.par
Net-SSLeay-1.32-i386-linux-thread-multi-5.8.5.par
Time-Piece-1.11-i386-linux-thread-multi-5.8.5.par

That is, I know what the modules are, I just don't know which of our optional modules are pulling those in.

Comment 2

[Max Kanat-Alexander]

So this is set up and working fine now, but I still need to:

* Make perl 5.8.8 versions of the binary dependencies.

* Make x86_64 versions of the binary dependencies for perl 5.8.5 and perl 5.8.8.
  (Finding an x86_64 machine with perl 5.8.5 is going to be a trick.
   I have a Fedora 7 x86_64 machine here. Maybe I can install an old Fedora 
   in a KVM virtual machine, and that will do it.)

* Make a non-binary version of Template-Toolkit for repo.

* Modify the "makepars.pl" script (Steffen's script) to work without me having
  to answer CPAN's questions. (I just have to set certain env. variables and
  so forth--I know what they are.) It should also do some of the above things
  (like deleting GD and building a non-binary TT) for me.

* Make sure that the modules, as they are installed, correctly implement the
  various features we need in those modules for Bugzilla. (The LDAP module
  in particular needs ldaps: support and TLS support.)

* See if I can get the PARs working in a fashion where SOAP::Lite doesn't 
  pull in a billion optional dependencies. (There may be other modules like
  this, too, that have lots of optional deps we don't need.)

Comment 3

[Max Kanat-Alexander]

Oh, I should also note that I had to do Bad Things to the perl install on landfill to make this work--I had to manually install a new version of CPAN, Test::Harness, and AutoLoader, overwriting the versions shipped in the perl RPM. So things will break if the perl RPM gets upgraded. I could probably rectify this by having makepars use PAR itself and load the right versions from a local directory.

Comment 4

[Steffen Mueller]

(In reply to comment #1)
> Also, we can't really reliably ship the GD module, because it has a dependency
> against the particular version of libgd that it was compiled against. So that's
> one thing that people are still going to have to install themselves or from
> CPAN.

Hmm, I'm not sure. It might be possible to include the libgd from the system into the PAR. That way, the .par for GD.pm would use its own, local libgd. (Or whatever the so is called.) I don't have the time to investigate right now, but the key is the -l (or, less likely -a) switch to pp.

In the meantime, however, I agree that shipping a GD.par which relies on a specific libgd on the system is bad.

Best regards,
Steffen

Comment 5

[Max Kanat-Alexander]

I really think install-module makes things easy enough, and we don't need to use PAR now.

Comment 6

[mikedoak]

Hi Guys(and gals??), Steffan/Max/
I'm a "virgin user", as this is my first attempt to resolve issues thru an online team like you folks have.... I ran Bugzilla, after following the tutorials, for a day, and spending 6 hours just entering the 200 bugs I got on my bug report, when running your program.... I set up encryption, and followed all the directions I could, and will get myself up to speed, as far as the terms you use(install~module, PAR, libgd, .PAR for GD.pm, local libgd, -1 switch to pp, GD module, perl RPM, the Bugzilla tarball, a PAR repository, symlink, XS, XS Stash, mod_perl12, autoloader, or "configuration of the local Apache"(where are those Apache Indians, and Cochise, anyway??); I want to help, and learn, and so call me, anyone who might need any help, as I have at least 200 bugs to disable and get rid of, here(Mike Doak~~760/729~8111, in Carlsbad, CA).... Call me if you need me, and thanks, in advance, if I can help you any, along the way.... I'm headed to wikipedia, for my "terms tutorial", right now~~

Best regards,

Mike Doak