Bug#585755: dh-make-perl fails to notice "Config" as a core module

[Chris Butler]

On Wed, Jun 16, 2010 at 08:42:29PM +0300, Damyan Ivanov wrote:
> > I think the problem is that Module::CoreList does include 'Config', but not
> > its version number (it's in the version hash as "undef"), which indicates
> > that module is present in that perl version, but the version number is not
> > known/specified. 
> I think this is the core of the problem and the place where the fix 
> should be applied.

It is documented in the Module::CoreList POD:

       Note, it is possible for the version of a module to be unspecified,
       whereby the value is undef, so use "exists $version{$foo}{$bar}" if
       that’s what you’re testing for.

Not all modules define $VERSION (Config is one of them - it's specific to
the particular build of perl), so the work involved in fixing it would
possibly be non-trivial and manual.

> > The attached patch (against current SVN) fixes the problem, by only
> > performing a version check if the version passed into core_module_perls is
> > defined and non-zero (previously it was checking the version iff it was
> > defined).
> 
> I think this could have undesired effects.
> 
> The current logic (well not that current as you have committed the 
> patch, but let's ignore that typical nitpicking of mine for now) is 
> that if the requirement is for Foo 2.3 and Module::CoreList can't help 
> us, we better bail out. Perhaps a better message is in order, but 
> blindly assuming that perl includes any version of Foo if M::CoreList 
> only provides undef's seems wrong to me.

That's not what my patch does. If the requirement is for module Foo 2.3,
then we MUST have at least version 2.3 of Foo specified by Module::CoreList
(this logic should be unchanged from the previous version).

The change comes where the requirement is for module Foo, any version (i.e.
no minimum version requirement specified). In this case, we only need to
test for the presence of the module in CoreList (done in line 150); we don't
need the version check. Previously it was checking the versions if $version
(the requested version) was defined, even if it's zero or an empty string. 

> IOW, a requirement of Config X.Y should result in a dependency on perl 
> (>= Z.T), where it is guaranteed that perl Z.T really has Config X.Y 
> or later. The patch blindly assumes that unversioned perl dependency 
> satisfies any Config version requirement (IIUIC).

No, it assumes that an unversioned requirement for Config will be satisified
by an unversioned perl dependency. If the requirement was for Config X.Y,
then it would fail as core_module_perls would return an empty list.

> If we agree on this I'll reassign the bug to libmodule-corelist-perl 
> (and clone to perl-modules; doh, dual-life modules are annoying)

IMO, dh-make-perl is buggy as it's not dealing with Module::CoreList's API
as documented.

> > In addition, I had to make core_module_perls skip over a version key in
> > Module::CoreList::version if it was simply a "family" entry (i.e. "5")
> > rather than a full version entry, otherwise find_core_perl_dependency died
> > complaining about a strange version.
> 
> Why not fixing find_core_perl_dependency to support family versions 
> instead? Since they seem legal to me we better not error out.

I was 50/50 about where to fix that. I went for fixing core_module_perls, as
the POD suggested that it should return versions rather than families. If
you think that fixing it in find_core_perl_dependency is better, then I'll
amend it (and update the POD for core_module_perls to mention what it might
return).

-- 
Chris Butler <chrisb at debian.org>
  GnuPG Key ID: 4096R/49E3ACD3