Perl requires/provides proposal

[Chip Turner]

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.
> 
> In which way would this be different from making a Perl module depend on a
> path like "eval $(perl -V:vendorlib) && echo $vendorlib"? In both cases
> you would get an explicit versioned dependence. And for the Perl module
> package to be compatible with the main Perl package, the former would
> depend on a specific version+path provided and supported by the latter.

Well, as Warren showed, this can break if another module provides that
directory (which can happen from a third part perl module, or even one
of our own).  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.

Plus I don't like the idea of a non-vendor provided perl module
requiring vendorlib; it should require the lib of the target build
type (ie, site, vendor, or core).

Both approaches would work pretty mcuh equally in practice, but
sticking with the perl namespace approach lets us extend it later
(such as handling packages that embed perl, or some new perl compile
option that breaks binary compatibility).

> > Also, the perl module itself will explicitly own all dirs listed in
> > its @INC list.
> 
> Looks like a type mistake. I think it should read:
> 
>     Also, the perl package itself will explicitly own all dirs listed in
>     its @INC list.

Indeed, good catch.

> > 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?
> 
> What makes a dependence on a specific path from @INC less right than
> an explicit dependence on a versioned virtual capability?

The semantic meaning of the virtual capability vs the simple file
system assertion of a file/directory dependency (pretty much covered
above).

Chip

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