+++ This bug was initially created as a clone of Bug #522547 +++ --- Additional comment from bill-bugzilla.redhat.com on 2009-09-15 16:56:45 EDT --- I had a problem with the update not properly applying. After debugging it's not really the package's fault, but some improved Requires would help. It turned out my yum metadata was boned again. So, I had an previous version of perl-Email-MIME-Encodings. When checksetup.pl is run in %post, it was complaining about an older version of Email::MIME::Encodings, and not getting to pre-compiling my templates. So, the symptom was that the version displayed on the web page headers never got updated, even though all the code was installed fine. Looking at the SPEC, I see: Requires: webserver, patchutils, mod_perl, perl(SOAP::Lite), which I think we need to list all of the current perl module requirements and the versions (when checksetup will fail if they don't meet). In that case, I'd at least have seen RPM grumble at me rather than silently failing. Should I file a separate bug? --- Additional comment from emmanuel.seyman on 2009-09-16 02:58:41 EDT --- (In reply to comment #6) > > I think we need to list all of the current perl module requirements and the > versions (when checksetup will fail if they don't meet). Painful but I don't see any other alternatives. I'll ask around for opinions on this. > In that case, I'd at least have seen RPM grumble at me rather than silently > failing. Should I file a separate bug? Yes, please do.
Here's a stab at it: >Checking perl modules... >Checking for CGI.pm (v3.33) ok: found v3.43 >Checking for TimeDate (v2.21) ok: found v2.22 >Checking for PathTools (v0.84) ok: found v3.3 >Checking for DBI (v1.41) ok: found v1.607 >Checking for Template-Toolkit (v2.15) ok: found v2.20 >Checking for Email-Send (v2.00) ok: found v2.192 >Checking for Email-MIME (v1.861) ok: found v1.861 >Checking for Email-MIME-Encodings (v1.313) ok: found v1.313 >Checking for Email-MIME-Modifier (v1.442) ok: found v1.442 the 'perl' package doesn't seem to report its CGI version in Provides, so we have to assume 'perl' provides a sufficient one, I think. perl also includes PathTools (Cwd and File::Spec). Requires: webserver, patchutils, mod_perl, which, perl(SOAP::Lite), perl(Date::Format) >=2.21 , perl-DBI >= 1.41, perl(Template) >= 2.15, perl(Email::Send) >= 2.00, perl(Email::MIME) >= 1.861, perl(Email::MIME::Encodings) >= 1.313, perl(Email::MIME::Modifier) >= 1.442 I ought to file bugs on perl-DBI and perl so normal perl() versioning can be used, at which time the above could improve. But for now... >Checking available perl DBD modules... >Checking for DBD-Pg (v1.45) ok: found v2.13.1 >Checking for DBD-mysql (v4.00) ok: found v4.005 >Checking for DBD-Oracle (v1.19) not found I don't know how to handle conditional requires in RPM, and didn't find it in the Wiki. Usable tests are: perl(Bundle::DBD::Pg) >= 1.45, perl(DBD::mysql) >= 4.00 It looks like Fedora doesn't ship DBD::Oracle. perl-DBD-Pg should report a version for (DBD::Pg) but it doesn't. Another bug. >The following Perl modules are optional: Same question here, but they won't prevent installation, so punt.
Oh, I'm running this on Fedora 10: bugzilla-3.2.5-1.fc10.noarch I can do Fedora 11 next week, unless somebody happily beats me to it.
(In reply to comment #1) > > the 'perl' package doesn't seem to report its CGI version in Provides, so we > have to assume 'perl' provides a sufficient one, I think. FWIW, we've released Fedora versions with incompatible CGI and Bugzilla versions in the past. > perl also includes PathTools (Cwd and File::Spec). This shouldn't be relied on. There's no telling which sub-package of the perl package they could end up in. We need to test for perl(Cwd) and perl(File::Spec). > I ought to file bugs on perl-DBI and perl so normal perl() versioning can be > used, at which time the above could improve. Please do. > I don't know how to handle conditional requires in RPM, and didn't find it in > the Wiki. Standard procedures is to give all the rpms the same virtual Provides and put that in the Requires. At least, that was the case back in the RHL 6.x days and I've never seen anything to suggest it's changed since. > perl(Bundle::DBD::Pg) >= 1.45, perl(DBD::mysql) >= 4.00 These aren't required if you're using Oracle as a backend. > It looks like Fedora doesn't ship DBD::Oracle. perl-DBD-Pg should report a > version for (DBD::Pg) but it doesn't. Another bug. Yup. > >The following Perl modules are optional: > > Same question here, but they won't prevent installation, so punt. Optional modules are not, by definition, required. :-) (In reply to comment #2) > > I can do Fedora 11 next week, unless somebody happily beats me to it. What would be great would be a patch against rawhide's rpm. We could release these changes in rawhide and see if it breaks anything. If it doesn't, we can backport to F-11 and F-10.
> > perl also includes PathTools (Cwd and File::Spec). > > This shouldn't be relied on. There's no telling which sub-package of the perl > package they could end up in. We need to test for perl(Cwd) and > perl(File::Spec). based on the version checksetup wants, it cares about: perl(File::Spec) >= 0.84 > Standard procedures is to give all the rpms the same virtual Provides and put > that in the Requires. At least, that was the case back in the RHL 6.x days and > I've never seen anything to suggest it's changed since. do you just make up something here (bugzilla-database)? > > perl(Bundle::DBD::Pg) >= 1.45, perl(DBD::mysql) >= 4.00 > > These aren't required if you're using Oracle as a backend. right... so is there a construct for 'required if satisfying virtual provides'?
(In reply to comment #4) > > do you just make up something here (bugzilla-database)? Pretty much. It does require all maintainers agree on the virtual provide. > right... so is there a construct for 'required if satisfying virtual provides'? Not to my knowledge.
I couldn't find a perl-DBD-Oracle that wasn't defunct. It appears it has to be complied against non-free software, so I assume that's why. I'm not strong on the "we're Fedora, we don't give a damn about non-free software" theory, but the two choices seem to be either leaving the free-software user with a potential problem or causing the non-free-software user to have to waste some disk space (e.g. install one of the free ones). 'Overriding requirements' I'll disqualify as that'd break automatic security updates. perl-DBD-MySQL requirements look to be about 34MB of space, and perl-DBD-Pg requirements about 4MB. What would yum do for a user with neither of the two installed?
(In reply to comment #6) > > I couldn't find a perl-DBD-Oracle that wasn't defunct. It appears it has to be > complied against non-free software, so I assume that's why. I'm assuming it ships with Oracle, itself. > I'm not strong on the "we're Fedora, we don't give a damn about non-free > software" theory, but the two choices seem to be either leaving the > free-software user with a potential problem At this point, it should be noted that we're trying to fix a yum problem by hacking on Bugzilla's packaging. Any solution to the problem we can apply will be imperfect, per definition. > or causing the non-free-software > user to have to waste some disk space (e.g. install one of the free ones). Given the code quality of the modules, I don't feel comfortable forcing anyone who doesn't need either one to actually have one or the other installed. > What would yum do for a user with neither of the two installed? Install the shortest named rpm which satisfy the needed dependency (in this case, that would be perl-DBD-Pg.
Done in f13. I'll push the change to f12 in a week if nobody complains.
bugzilla-3.4.3-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/bugzilla-3.4.3-1.fc12
I've received mail that bugzilla-3.4.4-1.fc12 has been pushed to updates. The updates fixes this bug.