Re: Proposal: dpkg-perllibdeps

[Brendan O'Dea <bod@debian.org>]

On Wed, Jan 25, 2006 at 10:40:46PM +0100, Florian Ragwitz wrote:
>There were already some bugreports against debhelper that asked for a
>new dh_ script that handles the dependency analysis for perl modules. It
>has been tagged wontfix as the maintainer and author of debhelper thinks
>that debhelper is not the right place to do a complex such complex
>things like dependency analysis. He recommended that I should go the
>"dpkg-shlibdeps" way which does the analysis of dependencies with an own
>script which is then glued into debhelper with a small wrapper script.

I'm afraid that I'll have to disagree with Joey on this one.  This one
really should be dh_perlmoddeps or perhaps dh_perl, not in dpkg-dev.

That's not to say it needs to be in the debhelper package though, it
could be included in the perl package for example.

>This is what I want to do with dpkg-perllibdeps (the name is still
>object to change). I'm writing you to ask if this program could be
>included with the dpkg-dev package, what I would prefer over making it a
>seperate package. I'd like to use libmodule-scandeps-perl to do most of
>the work. This would introduce a dependency for dpkg-dev to this
>package. I don't know if that is tolerable for you. If not: how about
>shipping an own copy of Module::ScanDeps so it can be included into
>dpkg-dev. This has some disadvantages, obviously, but I don't like the
>idea of making dpkg-perllibdeps a seperate package.

I did some work on this when initially writing dh_perl.

Finding the modules is not the problem; A fairly simple regex will
locate all use/require statements correctly 95% of the time.

The problem is that last 5%.  There cases where modules are
conditionally used:

  eval { require Some::Module };
  require Some::Other::Module if $@;

or computed:

  require $module;

This is the reason I didn't include automagic module dependencies to
dh_perl: a solution which "mostly-works" ends up causing problems
when it goes wrong: modules with spurious dependencies on W32::*
packages etc.

A more reliable option would be parsing the "requires" from META.yml
files, although there remains the issue of mapping the version in the
case that the module is provided in core (possible, but tricky)--if
you've a solution along those lines I'd love to hear it.

--bod