This is a proposal I came up with after talking to Gabor Szabo about his Perl Ecosystem Development proposal.
One of the major "problems" we face while developing and deploying production Perl-based systems with Debian is that the state of the Debian CPAN modules is depressingly outdated. As an example, we're using Catalyst in Lenny, and that dates back to 2008 for the most parts.
This is just not enough.
A solution: maintain your own APT repository
Our current solution is to manually package every bit and maintain our own internal Opera APT repository that our servers and applications depend on. That's not optimal for two reasons:
- we have to package lots of modules, due to interdependencies, dedicating a fair amount of time to this activity that is not exactly "productive"
- we can't trust our systems to be Debian anymore, since we're updating bits and pieces with the bold assumption that everything will work fine
Of course, 99.999% will work fine, since it's Perl, but the problem is that one day this could fall down on our heads.
So, given the problem, what are the solutions?
- Continuing to manually keep an apt repository. Downside: Some(tm) waste of time
- Use a different packaging/deployment system, like PAR::Repository. I would personally like this, but it doesn't eliminate the need to maintain an own repository. You just don't use
dh-make-perland friends, that are, IMHO, nice to have and useful
- The "DebPAN"
I know Jeremiah Foster, and at a couple of Perl events I heard him talking to other CPAN/Perl developers about these issues. His answer would probably be to file a request for packaging for the modules we're interested in.
The reason why that doesn't work is that the lead time for a given RFP to land on Debian stable is unacceptably long, and I realize that is for a good reason. After all, it's supposed to be stable, right?
What about a "DebPAN" repository?
That could be a 3rd party APT repository, something like
- maintained by a close group of Perl/Debian/CPAN developers
- guaranteed to have a selection of the most important modules (more on that…) in a reasonably recent version
- targeted to Debian stable, and maybe other distributions? I think Ubuntu 10.04 suffers from this same problem, but much less than Debian Lenny, just to pick two versions
- maybe even with patches applied?, but that might be way too much, actually
The can of worms
Of course, lots of problems can arise. However, if we think this is a good idea, then we should try to have something even minimal up and running. Then we'll worry about all the problems…
However, who gets to decide the most useful modules? That should go by popular demand I guess. Even looking at Debian requests for packaging stats, maybe? I can also imagine that bigger companies using Perl would be interested in this to potentially save lots of "infrastructural work".
I'd be really interesting to know other people opinions on this, especially if they use Debian stable, Debian developers, or the Debian-Perl group itself.