User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Build Identifier: 2.23.1 Lock of an included .spec file makes integrating Bugzilla into RPM based operating systems more difficult. I'm attaching a .spec file and .conf file for Apache setup that work well for me. Reproducible: Always
Created attachment 222818 [details] bugzilla.spec file for RPM compilation of 2.23.1 Requires bugzilla.conf file for compilation. Based on RedHat/Fedora Core compilation and layout.
Created attachment 222819 [details] bugzilla.conf file for bugzilla.conf file for /etc/httpd/conf.d on RedHat/Fedora Core style systems, for SRPM compilation.
Oooh, pretty. :) I've been wanting to do this for a while, but I've kind of been stalling on the rest of the path location config stuff getting done so the paths of various Bugzilla files can be configured so everything isn't inside the webroot. Notes: globals.pl and CGI.pl are both going away in order to make mod_perl support easier. They'll be gone before 2.24 (or 3.0?) ship. Also, I'm not sure if it's appropriate to call them top-level modules like this (in the Provides: lines), since nothing outside of Bugzilla should be using them anyway.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think it's definitely good to have an SRPM, but I think we'd rather have packagers package Bugzilla by themselves, instead of including the package file inside of our CVS. Actually, right now Fedora Extras is working to package Bugzilla. The Red Hat Bugzilla is down at the moment, but just search for Bugzilla at http://bugzilla.redhat.com and you'll find it.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WONTFIX
Oh, I didn't notice Dave's comment. Dave--see my comment. What do you want to do?
Including a spec file is nice to people who like to use RPMs to manage things, regardless of packagers. If you're using RHEL for example, and the RPMForge folks haven't picked it up, then you grab upstream and build it. I'm always happen when I find a spec file included in stuff that none of my usual RPM providers are packaging, even if it's an RPM intended for SuSE or Mandrake that I wind up having to edit the hell out of to make it build on RHEL, it's still better than making a spec from scratch. :) On the other hand, I still think it'll make better sense once our configuration stuff works sufficiently well enough that a packager can make the package LSB-compliant without patching the hell out of it.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Maybe I should send this to Fedora Extras as well: do you have a name there of someone to send it to? I'd have to test yanking the "Provides", but I think that keeps RedHat's rpmbuild from whining about Perl dependencies. I can't test it today: my current consulting gig just ended, and my home machine is Windows for games. Working out the Perl dependencies was nasty work: I started from the old Bundle::Bugzilla package at CPAN, which could also use some work. Building things from CPAN is always awkward because it automatically grabs the latest versions of bundles, not the ones built into or known to work with a specific OS version. A good RPM gets away from that. If you plan to re-arrange Bugzilla for FSH in the future, great: this leaves a standard for developers to work from, and I've left the structure in place for you in the .spec file, where it currently sets the prefix to /var/www/html/bugzilla. In fact, if you want it to be HTTPS-only access, I can set that up in the bugzilla.conf file and even move it aside to /var/www/bugzilla to avoid standard /var/www/html access seeing it at all.
Nico: Here's the Fedora Extras bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188359 I would suggest you work with them--they have extremely high packaging quality standards, and they've already gone through a few rounds of review on their .spec file. Perhaps you could help them out.
Bugzilla has now been published in Fedora Extras.
Status: NEW → RESOLVED
Last Resolved: 12 years ago → 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.