Perl requires/provides proposal

[Michael Schwendt]

On 15 Feb 2004 00:27:06 -0500, Chip Turner wrote:

> 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).

Ah, yes, I've had eliminated that from memory already. :)
(though, 3rd party perl modules should not pollute a build environment)

Dependence on a virtual capability is less likely to break, of course, if
the virtual capability is well-maintained. E.g. when you create some of
the virtual provides by examining @INC automatically. Perl 5.6.1 would not
search in 5.6.0 site/vendor locations, for instance.

> 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.

Yes. I was still focusing on the availability on vendor/site directories
in the perl package when they are in @INC, too.
 
> 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).

So true. Interestingly, $sitelib has been included within the main perl
package for a long time. Unlike $vendorlib. So, only perl modules which
install into vendor locations have had the need to find another way on
how to depend on the main perl package.

--