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: > > chr...@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.
signature.asc
Description: Digital signature
