OpenSourcery

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 CGI.pm 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.

Last week I posted about local::lib, some of the work I was doing on it, and what I wanted to get done.

Well, it's done (for now). As of 1.004001, local::lib comes with an example script that completely bootstraps local::lib into an arbitrary directory. It installs cleanly on a fresh install of Perl 5.8.8, just like this:

  wget -O- http://weftsoar.net/~hdp/scripted_install.pl \
    | TARGET=./local perl

(I copied the script to my server so the URL is shorter -- it's the same as what's on CPAN, though.)

Future enhancements:

• A shorter url (t0m suggested http://install.local-lib.pl, which would be pretty cute)
• Better shell/environment integration -- right now, you have to Just Know how to get at the directory that local::lib created for you
• Build tool integration, e.g. make locallib, make localinstalldeps (that's a bit of a mouthful)

Anyone have other suggestions for useful features?

local::lib is really, really fantastic. It's a simple module: it bundles up all of the settings and environment variables needed to install Perl modules into a private directory. By default it uses ~/perl5, but you can give it some other directory for an argument, so it's perfect for bundling dependencies with your application or installing things in a scratch directory for testing. (It also depends on the correct versions of toolchain modules needed to make things behave consistently, which is a sweet bonus.)

The Makefile.PL has a bootstrap mode, which means that you can configure and install local::lib into one of these private directories without having it pre-installed at all and without touching your @INC.

This is really great, but I want one step better; I want to be able to bootstrap local::lib into a target directory without having to find the latest version, unpack it, etc. I've been working on a script to do this, something like

wget -O- $some_url/local-lib | TARGET=./local perl

(possibly with some sort of integration with David Golden's -Mylib), but there are a few tangles I still have to work out.

I did make some progress yesterday. I found a bug in Module::AutoInstall that was breaking the normal installation of local::lib under some circumstances, and I fixed the bootstrapping code in Makefile.PL so that the latest version should install cleanly on Perl 5.8.8 (still the default on many operating systems). Hopefully I'll figure the rest of my problems out this weekend, and local::lib will become even easier to use.