Michael Schwendt <ms-nospam-0306(a)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(a)redhat.com
Red Hat, Inc.