Slashdot Mirror

← Back to Stories (view on slashdot.org)

Helping Perl Packagers Package Perl

Posted by samzenpus on from the dress-it-up dept.

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?"

4 of 130 comments (clear)

  1. At least the Perl crowd is trying, by Animats · · Score: 4, Informative

    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.

  2. Re:CPAN was both why I started using perl and stop by adamkennedy · · Score: 4, Informative

    The CPAN installer hasn't had the Perl auto-upgrade bug in several years...

  3. Responding as a CPAN admin... by adamkennedy · · Score: 5, Informative

    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.

  4. Re:Better fix it somehow by Lennie · · Score: 4, Informative

    Please, have a look at dh-make-perl. The Debian (and thus Ubuntu) way isn't really that bad.

    # apt-get install dh-make-perl ; dh-make-perl --cpan Your::CPAN::Package --install

    --
    New things are always on the horizon