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?"
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.
if you have a list of offending modules, then by all means don't keep it a secret
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...
easy_install works just like CPAN. Download and install stuff so the standard distribution software management tools are now worthless for:
1. Knowing what is installed on which production machines (basic software inventory)
2. Reporting packages with dependencies on a package with a newly reported security issue
3. Automatically upgrading to new releases
4. Easily rebuilding and deploying to multiple hosts on different architectures and different releases of distros (possibly different distros)
5. Managing dependency conflicts between different packages
and more that escape me right now because I haven't finished my coffee yet.
CPAN, easy_install and their ilk are wonderful for the developer that needs a bunch of stuff to get their application working. They are evil incarnate for the administrator that needs that application to work reliably and consistently on more that a couple of machines.
There is a huge difference between "easily installing stuff" and managing systems. The second you add anything that "works around" the standard way of doing things, whatever standard you've adopted, you've abandoned all hope of having standard operating procedures and consistent production management.
This is why systems administrators get so edgy... Every developer, user, language community, or whatever, thinks their little exception makes life easier. Exceptions don't scale.
Ok, they do scale. They evolve into chaos.
Not really
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
This is why I packaged any non-standard modules with my application when I developed with Perl on my last job. By containing the modules within the app, I made it my problem to keep them up-to-date, and not the system administrator's.
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.
CPAN, Rubygems, and Python easy_install don't "work around" the standard way of doing things, they are tools that work across a wide variety of platforms, which don't share a standard way of doing things (and some of which don't have much of a standard to start with.)
It would certainly be good to have, for a each, seamless integration with the standard package manager or equivalent for each platform on which they work, but that's no small task for any of them.
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