Perl requires/provides proposal

[Ville Skyttä]

On Sun, 2004-02-15 at 07:27, Chip Turner wrote:
> Michael Schwendt <ms-nospam-0306 at arcor.de> writes:
> 
> > On 14 Feb 2004 23:48:20 -0500, Chip Turner wrote:
> > 
> > > So the plan is to add perl(:MODULE-COMPAT-5.8.3) (and 5.8.2, 5.8.1,
> > > and 5.8.0) as Provides to the perl package itself, and add this
> > > equivalent to any perl module: perl(:MODULE-COMPAT-$(perl -MConfig -e
> > > 'print $Config{version}')).  In other words, a module, when compiled,
> > > will require the :MODULE-COMPAT tag of the version of perl it was
> > > compiled under.
[...]
> Also, the dependency we're trying to express is 'hello,
> I'm a module, and I require a perl interpreter that can run a perl
> 5.8.3 module compiled with ithreads and perlio' not 'hello, I'm a
> module and I need any rpm that contains some specific directory'.  I'd
> like there to be semantic meaning for the dependency above simply
> asserting directory existence.

All this sounds good, but the $(perl -MConfig -e 'print
$Config{version}')) expression above does not cover the ithreads and
perlio and friends cases.  I think a special rpm macro generates the
correct virtual dependency would be welcome if the dependency would
cover other cases than just the version.

For example:

   Requires: %{perl_module_compat}

...which would expand to something like

   Requires: perl(:MODULE_COMPAT-5.8.3-ithreads-perlio)

This would make the dep generation easier and more robust.  On the other
hand, then it becomes an issue whether to use "perl" or "%{__perl}" or
something else in the macro body.  As long as it's the same thing which
is fed to "perl Makefile.PL" or "%{__perl} Makefile.PL" things should be
ok.  Oh, and providing those meta compatibility packages for older perl
package releases would be harder with the macro as there's no easy way
to drop in new macros from a package (think no macros.d directory).

This issue exists also even if there would be no special macro, and
AFACIS the best that can be done would be to document and encourage
packagers to use "%{__perl}" or "perl" or whatever consistently in both
the dep generation and building the module.  OTOH if the above macro
would exist, it would be more important as the choice would already have
been made in the macro body.  This should also be consistent with the
way the current %{perl_install*} variables are resolved, which currently
use "perl" but I've posted a RFE:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115156

Further, the ithreads and perlio cases are irrelevant for quite a few
pure Perl / noarch modules, and would add a "too strict" dependency on
the target mother Perl package.  IOW, it'd be
(:MODULE-COMPAT-x.y.z-foo-bar) where a (:MODULE-COMPAT-x.y.z) would
suffice.  I don't know if this is something to worry about though.