Slashdot Mirror
Helping Perl Packagers Package Perl
jamie writes "chromatic has a great post today on the conflict between OS distributions and CPAN's installations of perl modules, along with some suggestions for how to start resolving this maddening problem: '[Though Debian has] made plenty of CPAN distributions available as .debs, I have to configure my CPAN client myself, and it does not work with the system package manager. There's no reason it couldn't. Imagine that the system Perl 5 included in the default package... had a CPAN client configured appropriately. It has selected an appropriate mirror (or uses the redirector). It knows about installation paths. It understands how to use LWP...' The idea of providing guidelines to distros for how to safely package modules is a great one. Could modules request (a modified?) test suite be run after distro-installation? Could Module::Build help module authors and distro maintainers establish the rules somehow?"
Fuck perl.
... is one of the coolest languages ever! There, fixed that for ya.
A broken mess of modules distributed inconsistently is the quickest way to kill my interest in a platform...
Could a /. reader get laid? Could I go to bed before 4 AM? Could someone get me a real job?
No.
More seriously, not as CPAN works now. There is no "snapshotting" or "consistent distribution level" mechanism, so there is no mechanism to write consistent component compatibility lists, and no way for the existing CPAN to look back *out* into the operating systems available components. Even component naming is too inconsistent among distributions. And when different packagers fold specific packages into their basic Perl package, or components that are required for new modules move into the basic Perl package itself, you have dependency madness just waiting to bite you, very, very hard indeed if you let your local Perl integrator replace all the dependencies. This way lies Gentoo madness, and it's hideously unstable in the real world.
There are steps you can use, but they're dependent on Perl authors actually following packaging "best practices". Building RPM's from many perl components is fairly easy, especially with components like 'cpan2rpm' available, but then you have the crack-monkeys who prodoce component 1.00, 1.20, 1.201, 1.202, 1.2437, and then 1.30 and expect 1.30 to be considered "the most recent", and no way to flush the funky numbered ones from CPAN lest development continue and you get to 1.201 the hard way. And then there are idiots who can't be bothered to write actual Makefiles or Make::MakeMaker configurations, but each invent their own replacement for "make". And now that Perl 5.10 is out, too many "latest release" components form CPAN are going to simply demand updates to that new Perl release. What a wonderful crapshoot to upgrade your Perl, *on the fly* to a new major release simply because you want to print dates a certain way?
Then there's the continuing use of Apache 1.3 and the matching mod_perl by Debian setups, and the utter nuttiness of rolling *BACK* Perl components to be compatible with that. What a wonderful way to *completely* fuck up your existing deployed codebase as rolling back your Perl to perl-5.6 to revert the incompatible components for that one.
Oh, and don't forget the "site-lib" versus "vendor-lib" settings. God forbids most Perl authors be bothered to actually *CARE* about it, but it does make a different in whether a component will be loaded and actually used in place of a separately installed one deployed as part of the operating system's other dependencies or package management system.
At least the Perl crowd tries to solve this problem. The Python crowd has a terrible time coordinating distribution of third-party modules. That's why it's taking forever for Python 3.x to get deployed. Red Hat Enterprise 5, Red Hat's flagship product, still uses Python 2.4, released in 2004. (There's a Python 2.5 included, but it's not the one the system tools use.)
Perl has CPAN, which is reasonably well organized and well run. Python has the Python Package Index (formerly called Cheese Shop), but it's not well coordinated with Python releases. Things seem to be improving, but Python is 20 years old now and ought to have a mature distribution system.
How much Perl packages would a Perl packager package if a Perl packager could package Perl?
FreeBSD already does this! Installing a package via cpan will create the metadata and register a FreeBSD package.
The problem is module dependencies... any non-trivial module now has so many dependencies now that it is almost inevitable one will fail to install. And than you're kind of screwed (unless you go and build it b hand.) And then there's the insanity of auto-updating perl itself to get a module. CPAN's badly broken and needs to be replaced entirely, which is a lot of why I pretty much quit using perl for a long time. Recently, my job changed and I got a lot of perl code. Man, I miss Ruby now.
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
The CPAN installer hasn't had the Perl auto-upgrade bug in several years...
Is the parent a bad post, or a good troll?
Some responses if I may...
Perl dependencies are specified by class name, not by distribution package name. So (theoretically) as long as there's a way to resolve a class to a file (which is standard) and thence to an operating system package ("which package contains file X" shouldn't be that hard) then there's no reason that Perl package dependencies can't be mapped down into distro package space.
As for the versions, 1.30 is more correctly more recent than 1.2437, because the CPAN turns multi-part versions 1.23.1 into decimals using an admittedly icky triplet system where each part of the multi-part is normalised into three digits.
1.2437 is a normalised version of 1.243.7. Downstream distos have implementations of this logic available to them in places like CPAN::Version. But yes, it is a bit weird for the newcomer. It's the price of 5-10 year back-compatibility, alas.
As for Perl 5.10, almost nothing on the CPAN will depend on it. The current recommended back-compatibility targets are Perl 5.6.2 for low-level or toolchainy stuff that needs a decade of back-compatibility, or Perl 5.8.5ish (around 5 years) for regular things (which is the first version where Unicode became bug free and universally usable).
So Perl 5.10 is having almost no impact on compatibility, and won't for at least another couple of years.