Helping Perl Packagers Package Perl 130
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?"
At least the Perl crowd is trying, (Score:5, 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.
Re:At least the Perl crowd is trying, (Score:3, Informative)
Re:Works For Me. Closing Bug Report. (Score:3, Informative)
cpan on the other hand has only probably worked 50% of the time for me, with it frequently hitting an unresovlable problem with dependency's.
Re:CPAN was both why I started using perl and stop (Score:5, Informative)
The CPAN installer hasn't had the Perl auto-upgrade bug in several years...
Responding as a CPAN admin... (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.
Re:Really, who has time for pathetic Linux pkgmgrs (Score:2, Informative)
CPAN has had its problems, but it's been reliable for me (after learning its quirks). Even so, XS components which rely on shared libraries have added complexity to the distribution dependency resolution, configuration, and installation processes. Recent developments have improved this, but better integration with package managers can only help.
I did forget to mention BSDPAN (and a grant proposal to extend the reach of BSDPAN [perlfoundation.org]).
Debian solution ... (Score:4, Informative)
apt-get install dh-make-perl ; dh-make-perl --cpan Your::CPAN::Package --install
As for the CPAN client that asks too many questions - that's a matter of pre-configuring it for a distribution or for the installation options you chose when installing the distribution (it's not CPAN.pm's problem really, although it could indeed ask fewer questions).
The problem is simple to understand (Score:4, Informative)
In "Perl World" keeping Perl modules up to date is important. In "Distro World" maintaining a consistent and maintainable distro is important. These two desires are at odds with each other.
Does updating Perl Libraries ever result in some older Perl app or script breaking? My guess is that there is a strong possibility. Distro makers/maintainers are concerned that updates that occur without their knowledge will result in unpredictable chaos and difficult-to-track bug reports. By making the set up of CPAN deliberate, you are taking the destiny of your installation into your own hands -- and there is nothing wrong with that in the slightest, so long as you are aware and capable of managing your own operating environment.
Perl is an important, key-underdog player in the Linux ecosystem. I can't imagine Linux without Perl. However, the same goes for a few other components which are not updated by distros at the very same pace as the developers of those components release them. And there are many reasons for this -- good ones, bad ones and ugly ones.
Would it be nice if CPAN were configured right out of the box? Yeah... if you were a Perl developer. And there's nothing to stop a Perl developer from custom building his own Linux distro based around CPAN and all that. In fact, I would be really interested to see what a Perl centric Linux distro would look like. I believe an entire OS could be written in Perl... not saying it is a good idea, just that I believe it could be done ... from the memory management to the GUI interface, I think it could be done. But I am certain such a distro would be incredibly unique and speak of the differences of mind that Perl developers are known for. But it would be difficult and I think it would not take long before Perl fans begin to appreciate what distro-folk deal with... or it could be as perfect and ideal as Perlies say it would be.
Re:Better fix it somehow (Score:5, Informative)
# apt-get install dh-make-perl ; dh-make-perl --cpan Your::CPAN::Package --install
Re:At least the Perl crowd is trying, (Score:2, Informative)
Another option is using a package system that properly handles dependencies. http://www.nixos.org/ [nixos.org], for example, allows multiple Perl versions, multiple CPAN trees - and even within CPAN different module dependencies. That makes for predictable deployment, and can help development too when testing diffferent CPAN dependencies. Interestingly Nix can be used inside Debian. I have it on all my systems to test different setups. Way to go Nix! There is also an article on linux.com.
Re:Works For Me. Closing Bug Report. (Score:1, Informative)
Then I would say that you have no idea how to use CPAN. I have never had an "unresolvable problem" using CPAN.
Re:CPAN was both why I started using perl and stop (Score:3, Informative)
Please stop spreading FUD around. This bug (Perl updating itself through CPAN) has been fixed for several years.
At least once a month I need to setup a new Perl install with all the dependency-heavy modules and I have no issues whatsoever - if it's failing for you, you're clearly doing something wrong.
Have you considered asking for help instead of spreading FUD on Slashdot?
Re:Homebrew (Score:3, Informative)
In truth, all three languages run (though none of them pass the full test suite) and interoperate on Parrot today.
Re:At least the Perl crowd is trying, (Score:3, Informative)
easy_install works just like CPAN.
In practice, "easy_install" usually doesn't work. The problem is that it makes assumptions about where things are supposed to be that aren't followed by the rest of the Python community. Nobody is pulling the whole thing together into a coherent distribution.