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...
Ruby gems? PHP Pears? Python pies?
The World Wide Web is dying. Soon, we shall have only the Internet.
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.
This module installs a tool which installs modules directly from cpan but enforces the conventions of the native environment. So if there is a perl module from the debian repositories called kludge and the same module is available directly from cpan, the cpan module would understand that they were the same basic thing, and know how to relate the different versions.
http://michaelsmith.id.au
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
if you have a list of offending modules, then by all means don't keep it a secret
oh, damn, somebody's already asked that....
Ask me about repetitive DNA
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.
If you mod me down, I will become more powerful than you can imagine....
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.
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).
how to invest, a novice's guide
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)
This isn't just a Perl problem; there are several packages that I know of that different distros have problems with.
I think it's more the nature of F/OSS: anybody that can repackage things, will -- just like anyone that wants to, can cobble together their own distro.
I don't see the problem going away for Perl, or any other package -- or even for the various distributions. As long as there are True Believers in .deb vs .rpm vs. git, /usr vs /opt, Gnome vs KDE, and so on, I see it continuing to be a problem. Nobody wants to give up a little bit of their "freedom" to do-as-they-damn-well-please in order to establish some consistency and minimum standards so as to make life easier for mere users. I've previously suggested that the fragmentation of Linux (of which this particular situation is just an example) is what's REALLY keeping Linux off more desktops.
But, hey, what do I know? I'm just one of those folks that only wants to get actual productive work done, and remembers what it was like for me when I made the switch from Windows(tm) to Linux.
--- Asking inconvenient questions for over 30 years...
Seriously, if Debian is 'breaking functionality' that makes part of their own distribution unusable, wouldn't it makes sense to file a bug report directly with Debian? While you are at it take all the Perl package maintainers and have them help elevate the priority of that bug report so they can't just ignore it. Having it officially declared a bug would be a logical first step.
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
As usual, Gentoo is a step ahead of the competition in this regard (and has been for a long time):
jps@karma ~ $ eix g-cpan
* app-portage/g-cpan
Available versions: 0.13.01 0.13.02 0.14.0 ~0.14.1_rc1 ~0.15.0 0.15.0-r1
Homepage: http://www.gentoo.org/proj/en/perl/g-cpan.xml
Description: g-cpan: generate and install CPAN modules using portage
Since Portage is only a collection of installation instructions, any kind of vendor package is suitable for it; this is unlike the primitive package managers that come bundled with every other distribution that still have problems with vendor packages as well as software which they have no license to redistribute.
For your next trick, I'll bet you'll tell us that emacs > vi
Fuck 'em both; ed is The One True Editor.
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.
Sure sounds like a good thing we never got Ruby/Perl/Python on parrot. They can't agree on anything, now imagine making it a requirement that they work coherently inside the OS' distribution systems and let modules/programs written in one call the others, and expect it to work, flawlessly.
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?
Perhaps those of us who write new Perl 5 code in 2009 are better at writing maintainable code than you were in 1999 or 2000. Certainly I'm much better at it than I was in 1999, especially considering the tools and community standards that have emerged since then.
how to invest, a novice's guide
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
They probably know the difference between a language that was designed using sound software engineering principles (Python) and one that was thrown together piecemeal by a madman, albeit a mad genius (as Larry Wall himself freely admits.)
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun