What's the best way to turn CPAN modules into Debian packages?

Question

Whenever I work on a system of any flavor that has a particular way of handling package management, I try to stick with that standard for managing my Perl modules. "When in Rome, etc."

For example, on a Win32 system using ActivePerl, I use PPM for everything and use the great PPM::Make. On a RedHat system I prefer to use RPMs.

Now I am working on a Debian system, and find myself in need of a way to turn an arbitrary CPAN or CPAN style distribution into a deb.

Google shows options like dh-make-perl, CPANPLUS::Dist::Deb and CPAN::Packager::Builder::Deb.

Does anyone with experience with these different tools have any recommendations as to what to use or avoid?

What's the best way to handle building deb files from standard CPAN modules?

Update:

I found an article by Hans Dieter Piercy on this subject - he suggests, for his own needs, CPANPLUS tools. Under some circumstances he recommends dh-make-perl. Jeremiah Foster (who wrote the article brian d foy points to) responds to HDP and makes a case for dh-make-perl.

There's also a post on idimmu.net that describes using dh-make-perl.

ATM, I'm leaning toward dh-make-perl, since that has been thrice recommended (brian d foy as proxy for Jeremy Foster, the idimmu.net author and hillu) vs once for CPANPLUS

Answer 1

dh-make-perl does a good job in taking care of the repetitive and heavy lifting and guessing information from the sources. It has worked correctly for almost all of the CPAN modules that I have packaged up as Debian packages (official or for in-house use only).

That said, the resulting package should only be considered as a starting point for a proper Debian packages. dh-make-perl puts warning notes into the automatically generated such as debian/control (i.e. description of the package and dependencies) and debian/copyright (licensing information).

In response to Manni, I believe that it is a great idea to work with the tools that the OS or distribution provides for package management, not against them. In the case of Debian, this means putting stuff into .deb packages and installing those. Perl's build tools and CPAN do a great job of providing a cross-platform build environment and for distribution of the source code, but compared to package management tools in modern Linux distributions, they perform suboptimally, simply because extra manual intervention is often required that is less easily automated across multiple machines than rolling up a package.

(For one-off and test installations, installing into /usr/local/ and using stow(8) as a poor man's package manager may be okay.)

Even if you are just building the packages for your own use, consider contacting the Debian Perl Group and have someone sponsor an upload to Debian if you feel that the module in question is of use for other people.

Answer 2

I suggest you ask the Debian Perl Maintainers group, rather than here on SO. Just mail the address shown as maintainer on any odd package:
Debian Perl Group <[email protected]>

Back in the day, I added a few modules to Debian, and just 'did it by hand'. I still maintain some. That isn't hard either. but the group now maintains way more package, and has tools.

Answer 3

Jeremiah Foster published an article about turning Perl distros into Debian packages in the Spring 2009 issue of The Perl Review.

Answer 4

There is a very good step by step here as well. (also with links to other good resources and some decent comments. [it is dated 2005, but still mostly relavent and many comments much more recent])

http://www.debian-administration.org/articles/78

here is the debian perl policy (also linked to in article) http://www.debian.org/doc/packaging-manuals/perl-policy/

Answer 5

You won't like this, but I really think that you should not do this at all. The various Perl Debian packages aren't for developers that need certain Perl modules on their machines. They were built because other applications need them and users want or might want those applications.

Please take a look at the answers to this question before doing something that you probably should not be doing.