Packaging CPAN Modules for Debian

Friday, June 5, 2009 - 14:57

I'm giving a talk on CPAN at this year's YAPC in Pittsburgh. One of the things I plan to mention is the cpan2dist program from CPANPLUS. I use cpan2dist (with CPANPLUS::Dist::Deb) to build Debian packages for our internal use.

I had a conversation on IRC this morning with someone who asked, roughly, "What's the difference between cpan2dist and dh-make-perl?" Until recently I don't know that I would have been able to answer this, and I think the answer reveals a distinction that is important to keep in mind whenever you're trying to bridge between CPAN and your operating system's package manager.

Specifically, I think dh-make-perl is for maintaining a Debian package that happens to be a Perl module, and cpan2dist is for wrapping modules from CPAN in a package manager-friendly way. Let me expand on both of those:

dh-make-perl was written by Debian people, and seems aimed towards people who would like to maintain a module in full Debian style, filling in all the metadata like a changelog and description and so on.

  • It leaves you a source tree with a debian/ directory, so it's easy to take the autogenerated files and go from there on your own.
  • It lets you easily tweak an individual package's Debian package information.
  • It does not recurse into dependencies at all, it just notes them in the generated debian/control file, though I think by default it will warn and ignore any dependencies that don't have a Debian package.

If there are one or two modules you need to install that aren't in Debian -- maybe because they're internal code -- and you don't mind maintaining the Debian metadata, you probably want dh-make-perl (or to submit a request for packaging bug to the Debian Perl Group).

cpan2dist was written by Perl people, and CPANPLUS::Dist::Deb really only pays lip service to Debian's packaging conventions.

  • It assumes that modules' licenses permit redistribution, and fills the bare minimum metadata needed to install the package in many places.
  • It does recursively build debs of dependencies, and gives you some control over how to build all of those packages -- a common prefix to use in the package name, build tool options, etc.
  • It doesn't know anything about some of the weird historical decisions that have gone into Debian's perl (e.g. libcgi-perl is not but some distribution named cvswebedit), and does not (currently) give you quite enough control to make the packages it generates fit in with Debian's perl in every case.

I treat cpan2dist as a way of making it easier on my sysadmin to manage Perl modules that I would otherwise just install with the CPAN shell -- installing into /usr/local instead of /usr, for example -- and I don't try to match up with any of those historical edge cases. If you frequently need newer versions of modules than Debian provides, or if you want to install a lot of internal Perl code as debs (especially if you have an internal CPAN mirror that your code is injected into, e.g. with CPAN::Mini::Inject), or if you don't really feel like interacting with Debian's perl much at all, you probably want dh-make-perl.

(Disclaimer: I do not use dh-make-perl with any regularity, so my assessment of it may be insufficiently deep. Please correct me if I've said anything wrong.)

Long term, I'd like to be distributing my own perl package, at which point I'd be using apt-get and dpkg as a convenient distribution and management mechanism. cpan2dist is a much better fit for that goal -- I don't want to have to spend the time munging each Perl module's Debian package's control files for use with my own perl.

If you aren't using Debian, there may be something like dh-make-perl written specifically for your packaging system (I'm aware of g-cpan and g-cpanp for Gentoo, and I'd be amazed if RPM didn't have something too). cpan2dist should work the same everywhere; it has backends for Arch, Gentoo, Deb, RPM for Fedora and Mandriva, and finally PAR, which is itself cross-platform.

In every case there will probably be this same tradeoff between tighter integration with the native package manager's assumptions and ease of use for installing arbitrary CPAN modules, so be prepared to choose one or the other.

Tagged as: 


The function of dh-make-perl

<p>The function of dh-make-perl is to package a Perl module. "Recurs[ing] into dependencies" would therefore mean packaging dependencies, not merely finding existing packages. That's why I mentioned dh-make-perl's behavior with dependencies that do not have Debian packages (that it warns mid-build but does nothing else).</p>


My favorite from the manpage of dh-make-perl:
Fail if a dependency Perl package
was not found (dependency
tracking requires the apt-file
package installed and updated)

this enables for sufficiently quick and easy dependency resolution.

dh-make-perl is probably better to use than CPANPLUS

While I think your blog post is pretty balanced, I would still prefer to create packages with dh-make-perl over CPANPLUS. Here are my reasons;

1. The point of packaging is distribution, therefor I would use the 'canonical' packaging tool. This will make sure you are following debian perl policy and while that may feel too 'strict' for you, it will help to assure you that you are not violating licenses or copyright. This helps prevents lawsuits.

2. dh-make-perl is actively developed (git repo here:;a=summary) I spoke with Kane (Jos) who maintains CPANPLUS and we talked about updating some of the internals of CPANPLUS to make debs better, but I not done any work on that and I don't think others have either.

3. Using dh-make-perl and improving it (it's written in perl :) ) means everyone benefits, not just those who use CPANPLUS.

Other good reasons: Packaging is not a black art, debian is free and open, aptitude is an excellent tool for handling package installation and you can combine it with your own local repos. Debian has lots of tools for managing repos too and lots of debian's tools are written in perl so you can hack them to your own needs.

dh-make-perl vs. CPANPLUS

1. The point of <strong>my</strong> packaging is <strong>internal</strong> distribution, so licenses and copyrights are no more of a concern than when installing via the CPAN shell.

2. I have comaint on CPANPLUS::Dist::Deb as of a month or so ago, and I'm fixing bugs as I have time, so I can certainly say that you're wrong that no one's working on it -- other people have also contacted me with patches since I announced my comaintainership.

3. I could just as well say that using CPANPLUS and improving it (it's written in Perl) means everyone benefits, not just those who run Debian or Ubuntu. I don't understand how this is any kind of argument for dh-make-perl over CPANPLUS. As I said in my post, they're good at different things (which is still true even if you meant CPANPLUS::Dist::Deb rather than CPANPLUS).

Your "other good reasons" are general reasons to use debs instead of the CPAN shell. I don't see how they point to the superiority of any particular solution.

I don't doubt that for <strong>you</strong>, dh-make-perl is more appealing than CPANPLUS::Dist::Deb. I can't agree that this is true for everyone else in every situation, though, which is what your reply title seems to say.

dh-make-perl vs. CPANPLUS

Indeed, even for internal distribution you will want to make sure you are not violating copyright and / or patented software. I am unsure about perl modules on CPAN that violate patents, but I know there are modules that are copyrighted by Oracle for example. This ought to make you nervous. Co-mingling that code with your GPL or Artistic license code base and then distributing it puts you at risk of a lawsuit.

I have seen situations where people install a perl module as a deb from CPANPLUS and they cannot un-install. This is obviously a huge problem. I can guarantee you that currently, dh-make-perl integrates source from CPAN much more effectively than CPANPLUS::Dist::Deb - this includes un-installing, correct maintainership and copyright attribution, up to the minute debian perl policy adherence, intergration into dpkg, etc.

I think it is excellent you are working on C::D::D. I also think using code and ideas from dh-make-perl would be cool because it has been hacked on by people who really understand debian and debian users expect debs to 'just work' with their system. It would suck if C::D::D made bad debs and debian got the blame for it. To avoid this I would follow the debian perl policy when hacking on C::D::D if at all possible. Or maybe just call dh-make-perl and dpkg-buildpackage from C::D::D - then you don't have to re-invent the wheel.

Add Your Comment Here

Hans Dieter Pearcey
OpenSourcery Alum