[packagers] Re: [svn] r6469 - trunk/rpms/perl-Apache-AuthCookie

Dag Wieers dag at wieers.com
Fri Sep 12 16:24:49 CEST 2008


On Fri, 12 Sep 2008, packagers at lists.rpmforge.net wrote:

> Author: dries
> Date: 2008-09-12 14:43:36 +0100 (Fri, 12 Sep 2008)
> New Revision: 6469
>
> Modified:
>   trunk/rpms/perl-Apache-AuthCookie/perl-Apache-AuthCookie.spec
> Log:
> fix
>
> Modified: trunk/rpms/perl-Apache-AuthCookie/perl-Apache-AuthCookie.spec
> ===================================================================
> --- trunk/rpms/perl-Apache-AuthCookie/perl-Apache-AuthCookie.spec	2008-09-12 13:10:48 UTC (rev 6468)
> +++ trunk/rpms/perl-Apache-AuthCookie/perl-Apache-AuthCookie.spec	2008-09-12 13:43:36 UTC (rev 6469)
> @@ -7,10 +7,12 @@
>
> %define real_name Apache-AuthCookie
>
> +AutoReq: no
> +
> Summary: Authentication and Authorization via cookie
> Name: perl-Apache-AuthCookie
> Version: 3.12
> -Release: 1
> +Release: 2
> License: Artistic/GPL
> Group: Applications/CPAN
> URL: http://search.cpan.org/dist/Apache-AuthCookie/
> @@ -21,6 +23,9 @@
> BuildArch: noarch
> BuildRequires: perl
> BuildRequires: mod_perl >= 2.0
> +Requires: perl(APR::Table), perl(Apache2::Access), perl(Apache2::Const)
> +Requires: perl(Apache2::Log) perl(Apache2::RequestRec)
> +Requires: perl(Apache2::RequestUtil) perl(Apache2::Response) perl(Apache2::Util)

Dries,

I am not convinced that this is the best way to implement this. The 
problem is that with future updates of the package you might miss new 
dependencies.

The cleanest solution is to change the execution of the automatic 
requires, by the same script and remove the ones we know are problematic.

What's even more, I think the package was designed to support both 
perl(mod_perl) as perl(mod_perl2) and therefor should probably take the 
correct decision (removing the other) based on the distribution we are 
running using _without_modperl or _without_modperl2.

In fact we are doing something similar for other packages and we should 
create a proper standard for things like this in the future so we handle 
it identical everywhere.

(I prefer a macro for this, but sadly that means we expect people building 
our package to have this macro...)

What do you think ?
-- 
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]



More information about the packagers mailing list