Perl requires/provides proposal

[Chip Turner]

The problem: It's not always obvious what perl RPMs under which an RPM
containing perl modules can run.  Perl itself is generally
module-compatible inside of major revisions, but currently we don't
build RPMs that have strong dependencies enforcing this (and
protecting from installing modules under different versions of perl).
Currently some perl modules have requires on the perl NVRE they want
but this requires manual intervention and epoch-awareness, which is
not always programmatically doable.

Proposed solution: All future perl packages will contain new provides
in the perl() namespace to specify both the modules they can run as
well as the embedded environments they provide.  All future perl
modules will contain similar requires.

Currently, all perl modules and the perl package itself have sets of
Perl provides and requires that are "namespaced."  These dependencies
look like perl(FOO) where FOO is a module name, or perl(:BAR) where
:BAR is a tag made up by me that means something to me.  Currently the
:BAR style tags are used for things that break binary compatibilty
(check "rpm -q perl --provides | grep 'perl(:'" -- things like
threading module, perlio, etc show up).

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 perl module itself will explicitly own all dirs listed in
its @INC list.  Some perl modules have requires on these dirs to solve
the problem above, and this would make those modules work, but that's
not really the right solution, hence the need for a more "official"
expression of the dependencies involved.

Thoughts?

Chip

-- 
Chip Turner                   cturner at redhat.com
                              Red Hat, Inc.