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

[Damyan Ivanov]

First thing first, sorry for the late reply. It seems updating the 
Bulgarian translation of www.debian.org is more attractive to me than 
dh-make-perl hacking. It is nice that others are interested in 
helping, though. Thanks!

-=| Chris Butler, Sun, Jun 13, 2010 at 04:33:34PM +0100 |=-
> Package: dh-make-perl
> Version: 0.68-1
> Severity: normal
> 
> When refreshing the packaging for libnet-ident-perl, dh-make-perl failed to
> find the "Config" module anywhere:
> 
> chrisb at crispylappy:~/src/Packages/pkg-perl/libnet-ident-perl$ dh-make-perl-dev refresh --pkg-perl --source-format '3.0 (quilt)'
> Engaging refresh mode in .
> …
> - Config  not found in any package
> …
> --- Done
> 
> However, the Config module is included in perl core (in the perl-base
> package).
> 
> 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.

> Interestingly, DhMakePerl::Utils::is_core_module correctly returns 
> the perl version that includes the module, but "core_module_perls" 
> returns an empty result.
> 
> 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.

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

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)

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20100616/306c4c01/attachment.pgp>