rpms/perl-CGI-Untaint-date/devel perl-CGI-Untaint-date.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2

[Ralf Corsepius]

On Thu, 2005-08-25 at 13:11 +0100, Paul Howarth wrote:
> Ralf Corsepius wrote:
> > On Thu, 2005-08-25 at 07:49 +0100, Paul Howarth wrote:
> > 
> >>On Thu, 2005-08-25 at 08:44 +0200, Ralf Corsepius wrote:
> >>
> >>>On Wed, 2005-08-24 at 12:34 -0400, Tom Callaway wrote:
> >>>
> >>>>Author: spot
> >>>
> >>>>Requires:  perl(CGI::Untaint) >= 0.07
> >>>>Requires:  perl(Date::Simple) >= 0.01
> >>>>Requires:  perl(Date::Manip) >= 5.00
> >>>
> >>>I think, these "requires:" probably are redundant.
> >>
> >>Why? The Makefile.PL specifically checks for these versions (or later),
> > 
> > == BuildRequires
> > 
> > 
> >>which is presumably done for a reason. RPM will auto-generate the module
> >>dependencies, but not the version deps.
> > 
> > True, but these already are implicitly covered by the BuildRequires.
> > So, if FE is kept consistent, unless you are mixing CPAN or various
> > repositories with FE, there isn't any need to check again at install
> > time.
> 
> Not necessarily; suppose A should require B >= 2.1, where B = 2.0 is in 
> [core] and B = 2.1 is in [updates-released]. Someone having installed 
> from CDs and not done any updates (maybe they're on dialup so they don't 
> use yum because it might take too long or be too expensive) might just 
> download A from Extras and install it. And it would break.
True, but ... IMO, this is yet another case of "not using FE
consistently", just like using CPAN or similar.

IMO, versioned perl-module deps, should not be applied unless rpm can
generate them automatically, because manually adding them voids rpm's
automatic perl-module deps to a large extend, and adds a considerable
(unreasonable?) amount of overhead to writing perl-rpm specs.

To put it differently: Not using manually added versioned perl-module
deps is a compromise, which doesn't do any harm unless users try to
enter corner cases.

Ralf