Bug 524309 - specify perl module requirements in Requires:
Summary: specify perl module requirements in Requires:
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: bugzilla
Version: 11
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Emmanuel Seyman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 525356 525357 525502
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-18 19:30 UTC by Bill McGonigle
Modified: 2009-11-22 18:50 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 522547
: 525502 (view as bug list)
Environment:
Last Closed: 2009-11-22 18:50:56 UTC


Attachments (Terms of Use)

Description Bill McGonigle 2009-09-18 19:30:41 UTC
+++ This bug was initially created as a clone of Bug #522547 +++

--- Additional comment from bill-bugzilla.redhat.com@bfccomputing.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@club-internet.fr 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.

Comment 1 Bill McGonigle 2009-09-18 21:42:59 UTC
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.

Comment 2 Bill McGonigle 2009-09-18 21:45:27 UTC
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.

Comment 3 Emmanuel Seyman 2009-09-19 08:42:40 UTC
(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.

Comment 4 Bill McGonigle 2009-09-24 03:10:34 UTC
> > 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'?

Comment 5 Emmanuel Seyman 2009-09-24 09:11:41 UTC
(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.

Comment 6 Bill McGonigle 2009-09-25 20:24:20 UTC
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?

Comment 7 Emmanuel Seyman 2009-09-25 23:48:35 UTC
(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.

Comment 8 Emmanuel Seyman 2009-11-11 19:08:36 UTC
Done in f13. I'll push the change to f12 in a week if nobody complains.

Comment 9 Fedora Update System 2009-11-18 03:04:56 UTC
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

Comment 10 Emmanuel Seyman 2009-11-22 18:50:56 UTC
I've received mail that bugzilla-3.4.4-1.fc12 has been pushed to updates.
The updates fixes this bug.


Note You need to log in before you can comment on or make changes to this bug.