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.
Fuck emacs.
Camping on quad since 1996.
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.
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).
"I love my job, but I hate talking to people like you" (Freddie Mercury)
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.
Sorry guys, but I do a LOT of really large perl based projects. CPAN is fine. Hell, it works better than the supposedly wonderful rpm and apt based package managers. At least when you install from CPAN you know the stuff WORKS because it actually gets tested. The CPAN dependency system works fine too. All I can conclude is that people who have had problems with it have a whole lot of RPM installed packages that were guess what? BADLY PACKAGED by the distro.
I agree, it would be great if CPAN and package managers coordinated. There are things CPAN certainly lacks, like transactions and any real ability to uninstall. What it does do, it does well.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
I feel that you have already answered the question yourself.
Some of us would switch if Python/Ruby/Whatever was ten times better than Perl. But it's not. In fact, if you are fairly experienced with Perl, you can do almost anything almost equally as good with Perl as you would do it with the others. Why go through all the trouble of switching when you have a tool that you know too well and you are completely comfortable with?
And what about all these guys that are bashing Perl every time it gets mentioned in /.? Judging from the fact that they are frequently:
one can easily understand that the Perl they are referring to is different than the Perl many people are using. In the real world, you can write perfectly readable Perl code that works very well and fast.
If one should start learning now, he/she probably could choose Perl or Python or Ruby and be equally as happy. Maybe even just a little bit happier with the last two, especially if you are care about code aeshetics. But if you already know how to use Perl to accomplish your task, IMHO trying to switch may involve a certain amount of wasted time.
Apologies to Python/Ruby guys, but I have yet to encounter a very compelling reason to switch from Perl for the tasks I've been using it. Maybe it's just me.
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?
In truth, all three languages run (though none of them pass the full test suite) and interoperate on Parrot today.
how to invest, a novice's guide