Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Helping Perl Packagers Package Perl

samzenpus posted more than 4 years ago | from the dress-it-up dept.

Open Source 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?"

cancel ×

130 comments

Sorry! There are no comments related to the filter you selected.

May I Be the First To Say This (-1, Troll)

sneilan (1416093) | more than 4 years ago | (#30542126)

Fuck perl.

Re:May I Be the First To Say This (5, Funny)

MadMartigan2001 (766552) | more than 4 years ago | (#30542140)

Fuck perl.

... is one of the coolest languages ever! There, fixed that for ya.

Re:May I Be the First To Say This (1)

Minwee (522556) | more than 4 years ago | (#30543806)

Remember, the first rule of Fuck Perl is that you do NOT TALK ABOUT Fuck Perl.

Re:May I Be the First To Say This (1)

HoboCop (987492) | more than 4 years ago | (#30543828)

Fuck perl,

python is one of the coolest languages ever!

There, fixed that for ya.

Happy to be of service.

Re:May I Be the First To Say This (1, Funny)

FooAtWFU (699187) | more than 4 years ago | (#30542142)

Fuck PHP.

FTFY.

Re:May I Be the First To Say This (0, Offtopic)

sneilan (1416093) | more than 4 years ago | (#30542218)

Yeah, PHP isn't great either, although, it's more legible than perl. I mostly use Python myself.

Re:May I Be the First To Say This (0)

Anonymous Coward | more than 4 years ago | (#30544196)

Fuck Python.

Re:May I Be the First To Say This (1)

flydpnkrtn (114575) | more than 4 years ago | (#30542146)

That's the kind of spirit that's made open source what it is today!

For your next trick, I'll bet you'll tell us that emacs > vi

Re:May I Be the First To Say This (3, Funny)

lena_10326 (1100441) | more than 4 years ago | (#30542152)

For your next trick, I'll bet you'll tell us that emacs < vi

Fuck emacs.

Re:May I Be the First To Say This (1)

sneilan (1416093) | more than 4 years ago | (#30542176)

Well, my next trick was actually going to be all about how I like vi. :)

Re:May I Be the First To Say This (2, Funny)

jonaskoelker (922170) | more than 4 years ago | (#30543724)

For your next trick, I'll bet you'll tell us that emacs > vi

Fuck 'em both; ed is The One True Editor.

Re:May I Be the First To Say This (1)

Randle_Revar (229304) | more than 4 years ago | (#30544574)

I am beginning to think emacs is, in fact, greater than vim (emacs is obviously > vi). But emacs key bindings are still far behind vim's

Better fix it somehow (4, Insightful)

Brian Gordon (987471) | more than 4 years ago | (#30542166)

A broken mess of modules distributed inconsistently is the quickest way to kill my interest in a platform...

Re:Better fix it somehow (4, Insightful)

Anonymous Coward | more than 4 years ago | (#30542202)

hasn't stopped people using windows

Re:Better fix it somehow (3, Insightful)

SheeEttin (899897) | more than 4 years ago | (#30542226)

Yep. A little while back, I was looking for an svn-bisect. Ubuntu has a perl svn-bisect in the repos, so I tried it. As far as I could tell, it didn't do anything, so I tried to get a newer version from CPAN. Now, how do I use this... It requires other modules? Okay, I'll grab them too. Now, how do I use THESE... compile them? Okay.
These require modules too? Uh, grab this one, and...
Screw it. I can live without.

Re:Better fix it somehow (1)

nedlohs (1335013) | more than 4 years ago | (#30542510)

Did:

perl -MCPAN -e'install "App::SVN::Bisect"

not just download, compile, and install it and all the dependencies?

Re:Better fix it somehow (1)

adamkennedy (121032) | more than 4 years ago | (#30542588)

Or, more recently, just

cpan App::SVN::Bisect

Re:Better fix it somehow (1)

nedlohs (1335013) | more than 4 years ago | (#30545080)

because everyone didn't have that as a shell alias already, though mine wasn't named cpan I guess.

Of course I haven't touched perl for 5 years, it's all python for me these days, so there'll be a lot of perl changes I know nothing about :)

Re:Better fix it somehow (1)

rtfa-troll (1340807) | more than 4 years ago | (#30543246)

no;

  1. because I'm not the administrator and so this means that I have an incoherent second module system in parallel to the system install. If it was an RPM the admin would just install it
  2. because I am an admin and the main reason I choose an RPM system is I don't want to lose track of my software so I don't want random software installed separately

The obvious, easy, already attempted by many people, is to use the CPAN infrastructure to build RPMs and DPKGs which people could then install and delete at will. The perl gods have had multiple fine chances to have this integrated but reject it every time because they know better.

perl -MCPAN -e'install "App::SVN::Bisect"

will be okay at the point where it installs the resulting libraries as proper packages suitable for the local package manager. Not before.

Re:Better fix it somehow (4, Informative)

Lennie (16154) | more than 4 years ago | (#30543330)

Please, have a look at dh-make-perl. The Debian (and thus Ubuntu) way isn't really that bad.

# apt-get install dh-make-perl ; dh-make-perl --cpan Your::CPAN::Package --install

Re:Better fix it somehow (1)

Randle_Revar (229304) | more than 4 years ago | (#30544386)

Mod parent up

Re:Better fix it somehow (1)

nedlohs (1335013) | more than 4 years ago | (#30543420)

Your false dilemma doesn't apply because the post I was replying to said they tried the module from CPAN but couldn't get be bothered with the dependencies.

Hooking CPAN up to RPMs or DPKGs is obviously the domain of those producing the distribution not "the perl gods". After all they know what their system's name and versioning format is, what paths they install things to, if they used stuff like /etc/alternatives, etc, etc, etc.

CPAN was both why I started using perl and stopped (4, Interesting)

Fished (574624) | more than 4 years ago | (#30542258)

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.

Re:CPAN was both why I started using perl and stop (4, Informative)

adamkennedy (121032) | more than 4 years ago | (#30542554)

The CPAN installer hasn't had the Perl auto-upgrade bug in several years...

Re:CPAN was both why I started using perl and stop (3, Informative)

acid06 (917409) | more than 4 years ago | (#30545322)

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?

Works For Me. Closing Bug Report. (1)

mpapet (761907) | more than 4 years ago | (#30542376)

Cpan works people. And it works well. It works on Windows(strawberry perl) it works on Debian, it works on Mac. When it fails, it's not that hard to figure out where and quickly get the scope/scale of the problem worked out.

Besides, it seems to me the whole packaging scheme is designed to be kind of loose on purpose. Criticizing it for a design feature is pointless.

If you really insist on blasting away at Perl, then you'll be blasting away at Python soon enough. Shocking but true, there are packaging issues with Python too.

Re:Works For Me. Closing Bug Report. (2, Informative)

timmarhy (659436) | more than 4 years ago | (#30542464)

Huh, what packaging problems? i've been a python dev for 5 years now and the closest i've come to a problem isa few funnies with py2xe.

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:Works For Me. Closing Bug Report. (0)

Anonymous Coward | more than 4 years ago | (#30542720)

Dependency's what?

Re:Works For Me. Closing Bug Report. (1, Informative)

Anonymous Coward | more than 4 years ago | (#30544688)

Then I would say that you have no idea how to use CPAN. I have never had an "unresolvable problem" using CPAN.

Re:Works For Me. Closing Bug Report. (0)

Anonymous Coward | more than 4 years ago | (#30542960)

It works on Windows(strawberry perl)

Right. Sure it does. Try to get the DBI to recognize Postgresql. I'll bet you a round of beer that it won't install. Ever.

CPAN was great. However, the sheer number of modules that don't even install is staggering and now CPAN is a bloody mess. I sincerely hope that with the (the time is near!) coming of Perl 6 it will be seen as a good opportunity to start all over with a fresh CPAN6.

Reopening Bug, closed in error. (1)

Medievalist (16032) | more than 4 years ago | (#30545676)

Close it when CPAN co-operates with the most common package manager on business linux systems - namely RPM.

Companies that make stuff that people actually need usually run SuSe or Red Hat, if they run any linux at all. Why not simply have a CPAN plugin that keeps the RPM db updated? Don't use it if you don't want it.

Ideally, Red Hat and Suse should be paying for this, since their customers would be the ones profiting by it.

Re:Better fix it somehow (1)

emilper (826945) | more than 4 years ago | (#30543072)

care to elaborate ? I mean: "broken", "mess" and "inconsistently" ? ... or were you talking about PHP, Python, Java, C, C++ etc. ? As far as I can tell, Perl has the easiest way to find and install a shared library of them all ... PHP and Java are coming along, though, with a similar setup ...

Yeah, no kidding (3, Insightful)

Giant Electronic Bra (1229876) | more than 4 years ago | (#30543432)

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.

And what other languages too? (2, Insightful)

FooAtWFU (699187) | more than 4 years ago | (#30542174)

Ruby gems? PHP Pears? Python pies?

How much (4, Funny)

Anonymous Coward | more than 4 years ago | (#30542198)

How much Perl packages would a Perl packager package if a Perl packager could package Perl?

Re:How much (5, Funny)

Anonymous Coward | more than 4 years ago | (#30542212)

I don't know, but I do know that Peter Python packaged a peck of CPickled peppers.

Re:How much (4, Funny)

grantek (979387) | more than 4 years ago | (#30542938)

Isn't it something like "Yo dawg, I heard you like to package Perl so I put a Perl packager in your Perl package so you can package Perl while you're packaging Perl packages" ?

Re:How much (1, Insightful)

Anonymous Coward | more than 4 years ago | (#30543364)

Not really

Re:How much (1)

Anonymous Coward | more than 4 years ago | (#30542746)

A Perl packager would package all the Perl it could if a Perl packager could package Perl

Re:And what other languages too? (1)

Dice (109560) | more than 4 years ago | (#30542240)

Gems would be a godsend. I have a repository with 86 packages in it for one of my clients who runs a RoR app, most of those are gems. Most of them are easy to package thanks to gem2rpm [rubyforge.org] , but there are a few which are a PITA and required me to patch the source, hack the spec file, or both in order to get them to install correctly. Even so, we end up losing half of the advantages of a modern packaging system since we need to re-build any updated versions ourselves.

Re:And what other languages too? (2, Insightful)

buchner.johannes (1139593) | more than 4 years ago | (#30543114)

You are thinking too small. Any package that has submodules/extensions has the same problem. Such software typically created and uses their own extension system.
Some examples: Firefox extensions, Apache+PHP applications (wordpress), emacs, claws mail extension ... Virtually any package that can act as a platform. Just take a look in your package manager.

The current idea is to push everything into the repo too. Good because it is reviewed and checked twice; bad as it is incomplete and inconsistent (half is over the package manager, half over another tool [e.g. cpan]).

One solution would be to make the package manager pluggable, so it can install subpackages sanely, and can access the repo of the other party.

Re:And what other languages too? (0)

Anonymous Coward | more than 4 years ago | (#30543278)

Ruby gems? PHP Pears? Python pies?

java beans!

Re:And what other languages too? (1)

RegularFry (137639) | more than 4 years ago | (#30543730)

I can say from the painful experience of my colleagues that Gems are just broken. It's hard to say precisely what the problem is, but I *think* it's human rather than technical. It's telling that several solutions to "fix" Gems have sprung up in the past few months.

The problem stems, I think, from a tendency for software developers to attach themselves to the cargo-cult of major-minor-teeny version numbers. Without solid release engineering, you've got no indication that (for instance) a minor version bump doesn't include functionality breakage, or that a certain release only includes bug and security fixes *and nothing else*. What it boils down to is that you might as well only have two versions: current and edge.

I also see no reason *whatsoever* to allow more than one gem version on a production server. This being supported has caused us some *hideous* problems in the past. It's not helped by gem authors completely ignoring that some libraries (rake is an example) that are available both as gems and as ordinary system libraries. What happens then is that you can have one version installed, a gem requiring a version that should match, and that require failing because rake exists outside gems.

One way to fix it would be to have a "distribution" layer on top of gems, where people would nominate a specific set of gem versions, and make sure that they work happily together *without* the Gem namespace existing. End users could then install gems from a specific distribution without caring about specific version numbers, knowing that version conflicts couldn't happen. Optionally, the distribution could take care of building binary gems, so that production hosts didn't need compilation tools installed. A not insignificant benefit of this would be that it could make gems compatible with the Debian packaging policy.

The only downside is that people would have to stop living on the edge. I don't see this as a bad thing.

As a music lover, (1)

Errol backfiring (1280012) | more than 4 years ago | (#30544040)

"Perl gem" sounds good!

And Santa will bring me peace in the Middle East!! (5, Insightful)

Anonymous Coward | more than 4 years ago | (#30542180)

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.

mostly a problem with ancient ancient modules (2, Insightful)

Anonymous Coward | more than 4 years ago | (#30542274)

if you have a list of offending modules, then by all means don't keep it a secret

Responding as a CPAN admin... (5, Informative)

adamkennedy (121032) | more than 4 years ago | (#30542582)

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:And Santa will bring me peace in the Middle Eas (1)

digitalhermit (113459) | more than 4 years ago | (#30543086)

There are tools that can do a decent job of packaging some modules. For example, using the CPAN2RPM tool you can create a SPEC file. The SPEC file can then contain a Requires and Provides section for generating dependency lists. These lists can contain version information such as a requirement that a package be within a particular version range. Frontend tools such as yum can then use these dependency lists to pull in appropriate modules contained in RPMs. But yeah, it won't (automatically) solve the bizarre and arbitrary versioning schemes of some modules, but it can be manually worked around by adjusting the RPM version versus the Perl module version.

At least the Perl crowd is trying, (4, Informative)

Animats (122034) | more than 4 years ago | (#30542182)

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, (4, Informative)

sneilan (1416093) | more than 4 years ago | (#30542236)

Python does actually have a distribution system with easy_install. On windows, the install is a little more complicated, but, other than that, easy_install works pretty well.

Re:At least the Perl crowd is trying, (5, Insightful)

mwa (26272) | more than 4 years ago | (#30543176)

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.

Re:At least the Perl crowd is trying, (2, Insightful)

Dog-Cow (21281) | more than 4 years ago | (#30543512)

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.

Re:At least the Perl crowd is trying, (2, Insightful)

DragonWriter (970822) | more than 4 years ago | (#30545470)

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.

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.

Re:At least the Perl crowd is trying, (1, Offtopic)

mcrbids (148650) | more than 4 years ago | (#30542380)

RedHat is somewhere between 1 and 2 years late releasing RHEL 6. The split of Red Hat Linux into Fedora and RHEL came back to bite RHEL 6, because when RedHat tried to release the responsibility of developing Fedora to the community, what they got in return was an overemphasis on nifty cool stuff while long-standing bugs, some very severe, went disregarded.

Turns out, people who aren't getting paid to do it only want to do it if it's fun! And so the quality of Fedora, which is what RHEL is ultimately based on, dropped, increasingly sharply, until Fedora Core 9 was so bad it was actually unusable! You couldn't even so much as change the font size in X before it would crash!

I wish I was kidding. It was horrible.

So RedHat got the hint, and for the last year has hired a legion of programmers to do little more than fix every bug they can find. There are reams and reams. Rumor is that Fedora Core 12 is ultimately in line to be RHEL 6. I'm using Fedora 10, and it's finally about as stable as Fedora 8.

We can only hope! RHEL 5 is really starting to show its age, and I have a suite of RHEL 4 servers that I want to switch over to something newer, but as old as 5 is, I'd rather make the jump to 6 as soon as it comes out than do another switchover in a year or two.

Re:At least the Perl crowd is trying, (0)

Anonymous Coward | more than 4 years ago | (#30542466)

Fedora Core 9 was so bad it was actually unusable!

Ah, I think I found the source of your problem: you were using an OS that did not exist!

You couldn't even so much as change the font size in X before it would crash!

I call bullshit. Either that or you didn't know what you were doing. I, and many others, changed font sizes in Fedora 9 with no problems.

Re:At least the Perl crowd is trying, (1)

King InuYasha (1159129) | more than 4 years ago | (#30542488)

There's no way in hell that Red Hat, as an American company, would use Fedora 13 as the basis for RHEL 6. So, almost definitely, Fedora 12 will be the primary release that RHEL6 is based on. There will almost certainly be some components cherry picked from Fedora 13, but Fedora 13 will not be the ultimate basis of RHEL 6.

Re:At least the Perl crowd is trying, (1)

placatedmayhem (816456) | more than 4 years ago | (#30542448)

RHEL5, released March 14, 2007, uses Python 2.4.3, which was released March 29, 2006. Given a reasonable package-freeze/testing/bugfix cycle, using this version seems about right. Also, Python 2.5.0 was released September 19, 2006 -- I know I wouldn't want to make a potentially major jump for all my system tools before publishing a major distro release.

Perhaps you should rethink the presentation of your point next time -- given what you've said already concerning RHEL5 and Python2.4, you should also be saying "RHEL5 uses Linux 2.6! That was released back in 2003!!!! ZOMG!!!"

In re: Python 3 migration, moving to the Python 3 series presents FAR bigger issues than addon-distribution, namely the changing and/or removal of some particularly widely-used items from Python 2.

I will agree with you that distribution of third-party modules can be annoying in Python, but that's not necessarily the Python developers' problem. Why should they be implicitly responsible for something that is third-party? Just because another platform is doing it? C'mon, that's a flimsy argument at best.

Re:At least the Perl crowd is trying, (1)

adamkennedy (121032) | more than 4 years ago | (#30542544)

I offered to port the CPAN to Python about 6 years ago as a gift from the Perl community, and I repeat the offer every now and then.

It usually goes down as well as you might expect when someone from Python people hear the word "Perl" anywhere in a coversation :)

In the mean time, we've quite successfully ported and adapted the CPAN model for JavaScript with OpenJSAN [openjsan.org] and (more recently) for C with The CCAN [ozlabs.org] (run by Rusty Russel).

Both of these are arguably more sophisticated than Python's packaging, although of course both of them are still down in the range of 100 packages.

Re:At least the Perl crowd is trying, (2, Informative)

Pjotr (88015) | more than 4 years ago | (#30543336)

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:At least the Perl crowd is trying, (1)

maxume (22995) | more than 4 years ago | (#30543368)

Successful coordination would mean always waiting for the last third party release, so the policy of not worrying about what third party folks are up to isn't really that bad.

Create a cpan package in your package manager (2, Interesting)

MichaelSmith (789609) | more than 4 years ago | (#30542192)

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.

FreeBSD - one step ahead (4, Interesting)

adri (173121) | more than 4 years ago | (#30542222)

FreeBSD already does this! Installing a package via cpan will create the metadata and register a FreeBSD package.

Re:FreeBSD - one step ahead (0)

Anonymous Coward | more than 4 years ago | (#30543576)

The level of ignorance on /. always amazes me. Thanks for posting this.

Re:FreeBSD - one step ahead (1)

Rich0 (548339) | more than 4 years ago | (#30543842)

With Gentoo it isn't seamless, but there is a tool that will create local overlay packages from a CPAN, and then they can be installed. I don't think you get automatic updates or anything like that, but you do get collision protection, and the ability to cleanly uninstall.

There are lots of upstream packages that don't give much thought to distros.

common lisp sort of does this (1)

Trepidity (597) | more than 4 years ago | (#30542256)

common-lisp-controller [cliki.net] is an attempt to make Common Lisp package management play nicely with Debian package management, so, for example, trying to load a package within ASDF (Lisp) finds the appropriate Debian package if it's installed (like the linked article discusses doing for CPAN).

Strongly package-manager-based distributions like Debian usually don't put a lot of effort into making stuff outside the distribution work well, though. If you want some C library that isn't in Debian, you're going to have to build it yourself and stick it somewhere, and all the stuff in Debian isn't going to know about it. Similarly, if you want some CPAN module that isn't packaged in Debian (the Perl equivalent of a third-party shared library that isn't packaged in Debian), you're going to have to muck with it yourself, and it won't be in the usual dependency chain.

The usual Debian answer to these sorts of problems is: well, if it's maintained, useful, and under a DSFG license, let's just package it! Things get much less nice if the user is installing a bunch of custom stuff, and especially trying to get locally installed and package-managed stuff to play together nicely. CPAN having trouble with that is just one instance of nearly every other system that has its own custom package manager, from Python to GNU R to Scheme.

Re:common lisp sort of does this (1)

icebraining (1313345) | more than 4 years ago | (#30543234)

If you want some C library that isn't in Debian, you're going to have to build it yourself and stick it somewhere, and all the stuff in Debian isn't going to know about it.

Or you replace "make install" with "checkinstall" and now it does! And it even relies on such packages for dependencies.

Really, who has time for pathetic Linux pkgmgrs? (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#30542266)

Perl has had one of the best package management systems of any language or operating system for nearly as long as Linux has even been around. In stark contrast every Linux package manager has been little more then a sad and pathetic joke.

The Linux mob is the one that needs to sort their shit out, but it'll never happen, it's not in their nature. It's not hard at all to link CPAN with another good package manager (for example, FreeBSD has done a fine job of this). Getting it to work with the jokes that are rpms, debs, etc however...good luck. And don't expect the Perl side to help much until the Linux side finally builds or adopts a package manager that doesn't suck complete balls.

Re:Really, who has time for pathetic Linux pkgmgrs (2, Informative)

chromatic (9471) | more than 4 years ago | (#30542618)

Perl has had one of the best package management systems of any language or operating system for nearly as long as Linux has even been around.

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] ).

Ah, the age old question (1)

gringer (252588) | more than 4 years ago | (#30542292)

How much Perl should a Perl Packager package, if a Perl Packager could Package Perl?

Re:Ah, the age old question (2, Funny)

gringer (252588) | more than 4 years ago | (#30542294)

oh, damn, somebody's already asked that....

Re:Ah, the age old question (1)

jayspec462 (609781) | more than 4 years ago | (#30543824)

Well, you said it yourself: The question is age-old...

GoboLinux has something that does this (0)

Anonymous Coward | more than 4 years ago | (#30542308)

Just new, in fact.

CPAN gets its own directory tree, and the user can install modules to it in the usual way, but system packages can also depend on CPAN modules directly. A dependency on "CPAN:XML::Writer >= 0.604" from a system package will install XML::Writer in the CPAN tree, rather than having everything repackaged and duplicated or conflicting with packages from the distribution. The aim is to cover all the common domain-specific package managers (so also RubyGems, LuaRocks, PEAR, ...) on the same level.

I have a paper on it in the Distro Summit at linux.conf.au next month, and until then an overview of the system [mwh.geek.nz] is in the linked blog post.

Not to be pedantic... (1)

carlzum (832868) | more than 4 years ago | (#30542318)

but "Helping Perl Packagers" or "Helping Package Perl" would be sufficient If you package Perl you're a Perl packager, and every Perl packager packages Perl at some point :)

why attack python? (-1, Troll)

timmarhy (659436) | more than 4 years ago | (#30542478)

it seems the first response on here is to attack python - no wonder you can't solve anything, you spend so much time trying to deflect attention away from what are obvious failings.

Homebrew (1)

mal0rd (323126) | more than 4 years ago | (#30542508)

It sounds like homebrew [github.com] provides a good solution. Perl (and Ruby and Python) already have mature packaging systems and they really don't need to interact with each other. So homebrew is a smart packaging system that plays nice with others.

Re:Homebrew (1)

mwa (26272) | more than 4 years ago | (#30543202)

Perl (and Ruby and Python) already have mature packaging systems and they really don't need to interact with each other.

False. Say you have libFoo and Perl, ruby and/or python wrappers installed via their "mature packaging systems." Now, libFoo has a critical security vulnerability that requires an updated package with an API change. The system package management tool will happily upgrade the library and break the wrappers you use for production.

There is no, sane way to use multiple software management tools effectively.

Re:Homebrew (2, Insightful)

perlchild (582235) | more than 4 years ago | (#30544438)

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.

Debian solution ... (3, Informative)

Lazy Jones (8403) | more than 4 years ago | (#30542698)

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).

Re:Debian solution ... (0)

Anonymous Coward | more than 4 years ago | (#30543818)

This is not a solution. When apt-get upgrades perl, it will not upgrade your corresponding CPAN modules. I'm not sure you even understood the original problem.

Re:Debian solution ... (1)

Randle_Revar (229304) | more than 4 years ago | (#30544458)

I am not 100% sure, but I think modern (dh 7.x) dh-make-perl will auto-answer a lot/all of the CPAN questions if you run it before you run plain CPAN

Not just Perl (2, Insightful)

Dorsai65 (804760) | more than 4 years ago | (#30542764)

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 [slashdot.org] 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.

On the money (0, Flamebait)

guygo (894298) | more than 4 years ago | (#30543188)

I totally agree. Linux has Balkanized, shoving anything that wants to run on all distros into the same problem. Anyone who has done an "upgrade" knows how maddening (and rediculous) this can be. But who (or what) is going to "standardize" Linux? Is FreeBSD the answer?

Re:Not just Perl (1)

Randle_Revar (229304) | more than 4 years ago | (#30544538)

1. You are wrong. The "fragmentation" has nothing to do with why Linux hasn't gone farther on the desktop

2. Even if the "fragmentation" was the sole cause of Linux not going farther on the desktop, I would not trade any of the choices we have for more market share. If people want to inflict Windows on themselves (although 7 is so bad), that is their problem.

3. "consistency and minimum standards" - someone has never heard of freedesktop.org

Same problem with RubyGems as well (1)

mcnazar (1231382) | more than 4 years ago | (#30542916)

I recall the same issue with the Ubuntu and the Ruby community over RubyGems.

Ubuntu packagers would have preferred the use of APT instead of RubyGems for Gem installations, despite the fact that APT's lagged behind RubyGems.

Bug Report Time? (2, Interesting)

hAckz0r (989977) | more than 4 years ago | (#30543124)

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.

Deep thoughts (1)

cntThnkofAname (1572875) | more than 4 years ago | (#30543130)

OMG alliteration screw c++

The problem is simple to understand (3, Informative)

erroneus (253617) | more than 4 years ago | (#30543220)

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:The problem is simple to understand (1)

shovas (1605685) | more than 4 years ago | (#30544066)

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.

I'm assuming you mean CPAN World? Because in perl world we want a stable base, too. Barring security bugs, you just can't willy nilly update a module in production.

Re:The problem is simple to understand (2, Interesting)

perlchild (582235) | more than 4 years ago | (#30544464)

I think it'd be nice if the perl/cpan crowd would release a "ready for production" subset of cpan, that would be built, then packaged into every distro. For the rest of us.

Re:The problem is simple to understand (1)

sabernet (751826) | more than 4 years ago | (#30544510)

Where I work at they get around this by installing differing versions of each module into it's own directory and having a core installed module load up the appropriate paths in @INC at compile time. All it requires is the scripter specify which modules they need and what versions of those via the 'use' statement.

It prevents newer versions from breaking older distros until such a time as when it's properly tested and vetted.

g-cpan (2, Interesting)

Deorus (811828) | more than 4 years ago | (#30543490)

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 [gentoo.org]
          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.

Re:g-cpan (1)

iggymanz (596061) | more than 4 years ago | (#30543798)

nah, gentoo comes up with collision warnings all the time for various modules that are already installed but another module wants to install them too. Gentoo is for people who want to fart around twiddling their machine all day long

Re:g-cpan (1)

Deorus (811828) | more than 4 years ago | (#30545016)

> nah, gentoo comes up with collision warnings all the time for various modules that are already installed but another module wants to install them too

A good system doesn't stop being good only because it is sometimes incorrectly used.

> Gentoo is for people who want to fart around twiddling their machine all day long

And the point is? I am not suggesting that people switch to Gentoo, only demonstrating that the problem being described in this thread has had a solution for a long time. The only reason why this problem persists is because people insist on using primitive package managers that do not split the package itself from the installation instructions. Packages should be distributed exactly the way their vendors deem appropriate, Portage is flexible enough to allow this, most other package managers are not.

Re:g-cpan (1)

shovas (1605685) | more than 4 years ago | (#30544232)

After 8 years of hardcore gentoo usage on home desktops and production servers, I'm a bitter, shell-shocked ex-user taking refuge with ubuntu.

I love the idea of gentoo but I just don't think it can work in practice at scale.

I always refer back to this forum post [gentoo.org] because it captures all of the problems of gentoo in a lengthy snapshot. That post is 26 pages long and started in 2006.

I love gentoo. About a year ago I got fed up with gentoo and installed other distros certain I'd never go back. But soon I was missing gentoo so I got back onto it for a few months. Then it broke again as usual just doing routine updates. That was the straw that broke the camel's back. I'm now on ubuntu and I'll try anything before going back to gentoo.

Not to troll (1)

gregarican (694358) | more than 4 years ago | (#30543694)

but what is the compelling reason that developers still stick with Perl, when there are more elegant languages out there? Python, Ruby and a few other scripting languages come to mind. I realize that Perl is a mature option, with lots of libraries/modules available. But at this point I can say the same about some of the others.

Perhaps because it would be too tough to totally revamp a project and rewrite it from the ground up? Even then the syntax and logic behind Python, Ruby, etc. are close enough that a decent developer could wrap their head around the nitty gritty details.

All I know is when I review some old Perl code I've written back around 1999 or 2000 and then place it alongside of similar work in Ruby I get cross-eyed over the asthetic ugliness of the Perl code. To each their own I suppose, so like I said it's not a troll. Just my US $0.02 :-)

Re:Not to troll (3, Insightful)

thanasakis (225405) | more than 4 years ago | (#30544272)

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:

  • citing problems solved years ago
  • mentioning Python/Ruby features that Perl has too
  • hell, even saying PERL and not Perl

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.

Re:Not to troll (1)

acid06 (917409) | more than 4 years ago | (#30545386)

Try looking at Perl code from 2009 instead.
You can say that Perl code from 2000 and Perl code written today are practically two different programming languages.

Differently from most other languages, Perl is an evolving language.

Just so you can get a clear example, compare the syntax of Perl code written using MooseX::Declare with whatever code you're dealing with:

    http://search.cpan.org/dist/MooseX-Declare/lib/MooseX/Declare.pm [cpan.org]

I bet if it wasn't for the dollar signs in front of variable names, you wouldn't even recognize it as Perl.

So, yes, Perl code from the 2000 is mostly crappy. Look for the newer stuff.

Better than ruby/gems (1)

prog-guru (129751) | more than 4 years ago | (#30544408)

I usually download the tar.gz for a perl module, then it's a simple 'perl Makefile.pl && make && make test'. Install honors DESTDIR, so then I can package it myself, every time. If my distro ever does release an updated module, my package system should pick it up then.

Gems on the other hand, I haven't been able to package at all. Best solution I've seen is Debian, they set up a 'quarantine' under /var/lib/gems, with it's own bin directory and everything, to keep gems away from Debian packaged ruby libs. Then you get to fight with vendoring, config.gem, initializers, etc. I got to the point on one app where I just gave up and copied the libraries into RAILS_ROOT/lib. I sure hope rails 3.0 improves this.

More generic complaint (1)

SnarfQuest (469614) | more than 4 years ago | (#30545164)

Perl has problems, but there's a lot more irritating problems in the FOSS world.

Why, for example, does everyone have to develop their own versions of 'make'? Sometimes using two or three different varients in the same package. The Linux kernel uses it's own configuration routines, while many modules use somethings else, and libraries will use yet another method. Every time you need to add a module to drive some strange hardware, you have to spend several days just trying to figure out how you are supposed to compile it, just because the author of that package found a "better" way of handling the build process. It's really bad when some parts of the build use automake/autoconf, others use plain make, and others use some self-developed construction. Pick ONE package build process, don't pick every one.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>