Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Fixing CPAN: Part 1 - Toolchain Communication 6 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • And if we ever want anyone that doesn't know Perl (who are by definition not competent with Perl) to install a Perl-based application from CPAN, we need to fix that.

    Is that really what we want to be aiming at? I mean, I think that CPAN (and CPANPLUS) is great, but the only people who know about it are Perl developers. It's great for us that the same method works (for some value of "works") on every platform that we use, but for the average user (or the average adminstrator of a computer with Perl installed) probably isn't a Perl developer and wants to install Perl and CPAN modules using whatever installation tools he is used to using to install the rest of his toolset.

    I'd love to see a way to make it easier for CPAN authors (or perhaps CPAN itself - or another project attached to CPAN) to create packages that can be used to install CPAN modules using packaging mechanisms that are native to various operating systems - whether it's rpm, deb, sis or something else.

    That's how you'll get people installing CPAN modules painlessly.

    • Yes, sysadmins that don't know Perl should be able to install the latest and greatest off CPAN.

      Yes, newbie programmers on the first day they start Perl should be able to install modules without having to deal with errors they don't yet know.

      You are correct that it would be better for users to use binary packages, and solutions for these exist.

      Unfortunately, nobody that I'm aware of has managed to find a way to package and maintain up to date a reasonably large subset of Perl. debian is at 3,000ish out of 11

    • Is that really what we want to be aiming at?

      Is that really what we want to not be aiming at? How does having a working CPAN toolchain preclude binary package repositories? Why should we not aim at having both?

    • I'd love to see a way to make it easier for CPAN authors (or perhaps CPAN itself - or another project attached to CPAN) to create packages that can be used to install CPAN modules using packaging mechanisms that are native to various operating systems - whether it's rpm, deb, sis or something else.

      Take a look at CPANPLUS::Dist::Deb [cpan.org] and debian.pkgs.cpan.org [cpan.org] and you'll see you and I are on the same page :)

      It still needs some more hacking to make it easier to write new C::D::* modules, but the concept works :)

      • one gotcha i found with using debian CPAN repo is that the installation dir is different from CPAN installation. and CPAN is not aware of what module is installed by debian repo. since CPAN module path is ahead of debian CPAN module in @INC. it may introduce problem when you accidentially installed a newer version module that is already installed by debian repo. the faulty module is however hard to spot sometimes.

        there is also dh-make-perl in debian. IIRC, cpan2dist works better than dh-make-perl.

      • Ooh. Very cool.

        Now, of course, personally I don't care at all about Debian packages. Where is CPANPLUS::Dist::RPM.

        Or have I just volunteered myself?

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.