Proposal for corporate people who are stuck with old system perl

So I read this post complaining about Mojo deprecating 5.8 support.
As far as I understand, there are 3 groups of people:
1) People using shared hostings, sometimes without the shell access at all; their problem with the old perl can't be solved, they just should migrate to another hoster.
2) People who use perlbrew and install all dependencies either into ~/perl5/ or maybe even them right into project/ with local::lib
3) People who use a native packaging system.

I myself belong to the third group.
First, because it's how things are done at my $job.
Second, because I believe this is the right way to do things, although I understand that many people think otherwise.

Now before I'll explain the main point of this post, here are the reasons why .deb/.rpm packages may be better than CPAN:
- your system administrators will be happy;
- you'll be able to provide dependencies on the external software (lighttpd/apache, mysqlclient, etc.);
- you'll be able to put in your package things outside of /usr/bin/ /usr/share/perl5 (I'm talking about debian/ubuntu here, but RPM world is probably similar);
- postinst/prerm scripts! they are awesome;

Ok, may be I'm not familiar with modern CPAN modules for these tasks, I never got time to play with MyCPAN::App::DPAN and other brian d foy's modules.
And of course you have to install your own debian repository and write some custom tools to make all this stuff work painlessly.
But still, I feel that debian packaging system is more advanced and mature that CPAN.
(Please don't bash me for this opinion, it's not the point of this post. Even if I'm wrong, first argument about system administrators still stands.)

Now to the main idea of this post.
Even if we have to deal (like to deal) with native debian/rpm packages, it doesn't mean we have to use system perl.
We could build our own perl-5.14 deb package with perl binary called /usr/bin/perl5.14 with @INC not intersecting with standard system @INC, then rebuild whole CPAN as libfoo-bar-perl5.14.
We could put all these packages into one common repository (well, one for each distribution out there) and open it to everyone, and setup the system which would rebuild all new cpan releases and put them there automatically.
Ok, maybe not all modules, but most of them are trivial to build with dh-make-perl utility.

Looking at debian.pkgs.cpan.org, I think I'm not the first one to come up with this idea, but that host looks pretty much dead. And the most important thing here is to make this repository updated automatically.

Actually, last summer 4 of guys from Moscow.pm group (including me) tried to build such thing ourselves. We coded for one day, got some progress going, and then never found enough momentum to finish it.
Anyone wants to try once more? :)

1 Comment

Just a note, as a system administrator, I generally have no problems with my developer users installing a local version of Perl and modules via perlbrew and local::lib. As long as their development work can be done without affecting the system, and can be contained to their user space, I'm a happy sysadmin.

Leave a comment

About Vyacheslav Matyukhin

user-pic I wrote Ubic. I worked at Yandex for many years, and now i'm building my own startup questhub.io (formerly PlayPerl). I'm also working on Flux, streaming data processing framework. CPAN ID: MMCLERIC.