Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Journal of LTjake (4001)

Wednesday January 07, 2009
02:55 PM

Joining the Debian Perl group

[ #38231 ]

At $work, we have a number of Ubuntu servers, and all of the developers use Ubuntu for their desktop OS. This has been the case since the 6.04 release of Ubuntu.

I'm the first to admit that I'm not much of a sysadmin. The general advice for installing modules, as I've read, was to install the version from the apt repository when available. No problem there. Other than that, I've always just used the cpan shell to install what I was missing. Apparently, over time, mixing the two methods tends to break down.

Last summer, i finally broke down and got familiar with dh-make-perl. It made creating .deb files for modules criminally easy. I also took this one step further and setup a reprepro-based deb repository on an internal server so all of our machines could benefit from the .deb files I had created.

In the spirit of giving back, I began to wonder how I could help out upstream by injecting some of these missing packages. It turns out that Ubuntu synchronizes its packages from the Debian unstable repository on occasion. So, how does one get things into the debian repository?

Enter the Debian Perl group.

To sum up their announcement, they basically handle all perl module related packaging tasks for Debian. After finding them on IRC and applying to the group I was quickly accepted and thrown into the fray.

I decided that it would be best to install Debian in a VM and do my packaging there instead of trying to hack around Ubuntu-specific issues. The Debian Perl site has a number of good guides to get you moving. I'll try to summarize the basics.

For new packages, one must first create an ITP or Intent To Package report. This comes across the line as a bug report filed against the "wnpp" pseudo-package. The reportbug tool makes this a trivial task.

The group uses an svn repository to keep track of all of their work, so the next step is to inject your initial work into that repository. svn-inject will take care of this for you, as long as you have the .orig.tar.gz, .diff and .dsc files. To get those files, I did the following:

  • use dh-make-perl to intialize the package: dh-make-perl --cpan Foo-Bar --pkg-perl 
  • cd Foo-Bar   
  • use debuild -S to create the source package   
  • finalize the process with the svn-inject helper

Once you've injected the new module, you'll need to massage all of the debian/* files to get them up to spec -- in which there are many nuances that I'm still trying to figure out. The folks on the IRC channel are very knowledgeable and have helped me numerous times there.

If you think your package is ready to go into the repository you can change the release status from UNRELEASED to unstable ("dch -r" helps here) and someone will review it. Hanging out in the IRC channel can speed things along. If all is well, they will take care of the rest from there.

To update an existing package:

  • check out the existing package from svn   
  • use uscan to get the new tarball   
  • use svn-upgrade to inject the new data into the repository

Again you have to massage the debian/ files based on the new tarball data and the same review process applies.

As things are uploaded, you'll get a fancy developer page, like this. Also, the Debian Perl group has a really great status page for the repository that can tell you when new upstream packages are available, or what's been worked on in the repository.

The aforementioned dh-make-perl helper, which is also under maintenance of the Debian Perl team, is undergoing some major refactoring. It is being re-worked in a more modular form down from it's monolithic 2000-line single-file status. At the same time, a test suite is being added so no further regressions will occur. I've tried to help out where I can, but this a huge task with many opportunities to screw things up, so the more eyes on the code, the better!

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.