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?"
Better fix it somehow (Score:5, Insightful)
A broken mess of modules distributed inconsistently is the quickest way to kill my interest in a platform...
Re:Better fix it somehow (Score:4, Insightful)
hasn't stopped people using windows
Re:Better fix it somehow (Score:4, Insightful)
These require modules too? Uh, grab this one, and...
Screw it. I can live without.
Re: (Score:2)
Did:
perl -MCPAN -e'install "App::SVN::Bisect"
not just download, compile, and install it and all the dependencies?
Re: (Score:2)
Or, more recently, just
cpan App::SVN::Bisect
Re: (Score:2)
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: (Score:2)
no;
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
Re:Better fix it somehow (Score:5, Informative)
# apt-get install dh-make-perl ; dh-make-perl --cpan Your::CPAN::Package --install
Re: (Score:2)
Mod parent up
Re: (Score:2)
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.
Re: (Score:2)
Hooking CPAN up to RPMs or DPKGs is obviously the domain of those producing the distribution not "the perl gods".
Hooking possibly yes; Providing the hooks they can hook onto is what the perl gods definitely could do and choose not to. To be honest though, even the hooking should be done by the perl people. If you want your libraries and applicatations out there and usable and you aren't in the top end of applications, then packaging is your own responsibility. Now, normally the answer at this stage is "it's given to you for free, if you don't like it go and fix it yourself". The thing, however, is that the perl c
Re: (Score:2)
debian managed get it working, with some minor idiocy with the perllocal stuff.
If debian can do it, anyone can.
CPAN was both why I started using perl and stopped (Score:5, Interesting)
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...
Re: (Score:2)
Bit me on Ubuntu 8.04. Which is still the most recent LTS release, and readily available at VPS providers like Slicehost and Linode.
Re: (Score:2)
Ah! The workaround is...
1. Use CPAN to upgrade itself.
2. Install everything else.
Re: (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?
Works For Me. Closing Bug Report. (Score:2)
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 i
Re: (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.
Reopening Bug, closed in error. (Score:2)
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: (Score:2)
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 (Score:4, Insightful)
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? (Score:3, Insightful)
How much (Score:4, Funny)
How much Perl packages would a Perl packager package if a Perl packager could package Perl?
Re:How much (Score:5, Funny)
Re:How much (Score:5, Funny)
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: (Score:1, Insightful)
Re: (Score:1)
A Perl packager would package all the Perl it could if a Perl packager could package Perl
Re: (Score:2)
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: (Score:3, Insightful)
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. ... Virtually any package that can act as a platform. Just take a look in your package manager.
Some examples: Firefox extensions, Apache+PHP applications (wordpress), emacs, claws mail extension
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 o
Re: (Score:2)
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
As a music lover, (Score:1)
And Santa will bring me peace in the Middle East!! (Score:5, Insightful)
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 (Score:2, Insightful)
if you have a list of offending modules, then by all means don't keep it a secret
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: (Score:2)
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 biza
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: (Score:3, Informative)
Re:At least the Perl crowd is trying, (Score:5, Insightful)
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: (Score:3, Insightful)
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: (Score:2)
Also, as you can't trust the module developers for maintaining compatibility, to tell a sysadmin to install the latest release of this list of 15 modules would give you headaches for support.
Unless something's changed from the version of the docs that Google found, Perl assumes that if you want version X of a module then any Y > X will also do. That makes it difficult to have multiple versions of a module without @INC games. It also only applies the version check after the module is already required; it doesn't apply it when deciding which file to load in the first place. That's just too damn late and makes the @INC games worse.
Right now, Perl essentially assumes that, for each module, every
Re: (Score:3, Insightful)
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 goo
Re: (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.
Re: (Score:2)
We've found that the sanest mix is to install the core OS packages that don't suck, then do a CPAN install of the rest to some /opt/project-cpan path.
That stack of 10 or 20 dependencies turns into a single project-cpan RPM/Deb, and the application just adds the /opt/project-cpan to it's include path.
Now granted, there's no standard tools for doing that... yet.
Re: (Score:2, Offtopic)
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 o
Re: (Score:1)
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
Re: (Score:2)
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
Re: (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: (Score:1)
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 (Score:3, Interesting)
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 (Score:5, Interesting)
FreeBSD already does this! Installing a package via cpan will create the metadata and register a FreeBSD package.
Re: (Score:2)
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 (Score:2)
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
Re: (Score:2)
Or you replace "make install" with "checkinstall" and now it does! And it even relies on such packages for dependencies.
Ah, the age old question (Score:2)
How much Perl should a Perl Packager package, if a Perl Packager could Package Perl?
Re: (Score:3, Funny)
oh, damn, somebody's already asked that....
Re: (Score:1)
Well, you said it yourself: The question is age-old...
Not to be pedantic... (Score:2)
Homebrew (Score:2)
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: (Score:2)
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 t
Re: (Score:3, Insightful)
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.
Re: (Score:3, Informative)
In truth, all three languages run (though none of them pass the full test suite) and interoperate on Parrot today.
Re: (Score:2)
In truth, all three languages run (though none of them pass the full test suite) and interoperate on Parrot today.
Thanks for your efforts to bring nirvana ever closer.
Re: (Score:2)
The people that create the language aren't the same people that look after the packaging system.
Re: (Score:2)
But when the packaging system people pick just random parts of the cpan architecture of the package, the cpan people get pissed.
That's why the cpan people have to pick the (minimal) parts that the rest of the system can depend on.
Those parts presumably, would also be more likely not to change between minor versions(and a change to those parts should be considered de-facto major version material).
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).
Re: (Score:2)
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 (Score:3, Insightful)
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.
Re: (Score:2)
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
Re: (Score:2)
I certainly don't use Gnome or KDE (although both are fine DEs), but fd.o is very relevant to me.
fdo projects I find important/relevant (usage and maturity of specs vary):
cairo, dbus, xdg-utils, xdg-user-dirs, enchant, poppler, hal (and its replacements), shared-mime-info, harfbuzz, fontconfig, libxklavier, fribidi, liboil, DnD, ewmh, menu spec, icon theme spec, .desktop spec, icon naming spec, x direct save, xembed, the old systray spec, the new systray spec, recent file spec, thumbnail management spec, st
Same problem with RubyGems as well (Score:1)
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.
Re: (Score:2)
The problem is the Debian maintainers. The Ruby community tried to work with them on integrating RubyGems with APT, so that you could have a command to turn a .gem into a .deb and have the best of both worlds. The Debian Ruby packagers weren't interested--it was "my way or the highway".
Bug Report Time? (Score:3, Interesting)
Deep thoughts (Score:1)
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: (Score:1)
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: (Score:3, Interesting)
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: (Score:2)
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.
Re: (Score:2)
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.
Part of the problem is that Perl's handling of module versioning is a bit half-assed. In particular, there's no support for having several versions of a module installed and the script selecting which to use (e.g., all 1.X are OK when X is more than 4, but 2.Y are no good because the API changed incompatibly). Right now, if there's two versions on the @INC path then it's pretty random which one you'll get (well, it will be the first on the path) and so scripts can't handle module API versioning over the lon
Re: (Score:2)
It sounds like you'd be interested in at Perl/Linux [sourceforge.net], a linux distribution where ALL programs are written in perl.
g-cpan (Score:3, Interesting)
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: (Score:2)
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: (Score:2)
> 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
Re: (Score:1)
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 m
Not to troll (Score:2)
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 d
Re:Not to troll (Score:4, Insightful)
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.
Perl 6 (Score:2)
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.
Perl's object system blows but it has CPAN.
Ruby is slow and its community doesn't get coarse-grained dependencies.
Python is memory hungry and breaks compatibility frequently.
Perl 6 fixes the object system and is finally on a steady march to reality. I would have expected Ruby or Python to win by now but my money is on Perl 6 being the best option in th
Re: (Score:2, Funny)
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.)
Re: (Score:2, Insightful)
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.
Better than ruby/gems (Score:2)
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 pack
Re:May I Be the First To Say This (Score:5, Funny)
Fuck perl.
... is one of the coolest languages ever! There, fixed that for ya.
Re: (Score:2)
Re: (Score:1)
Fuck perl,
python is one of the coolest languages ever!
There, fixed that for ya.
Happy to be of service.
Re: (Score:2, Funny)
FTFY.
Re: (Score:2)
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: (Score:3, Funny)
Fuck emacs.
Re: (Score:1)
Re: (Score:3, Funny)
For your next trick, I'll bet you'll tell us that emacs > vi
Fuck 'em both; ed is The One True Editor.
Re: (Score:2)
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
Re: (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 ment