I frequently use the cpan upgrade command to bring my Perl modules to their latest versions. Regrettably on distributions like CentOS which use ancient versions of Perl it attempts to upgrade perl itself along with other modules like B::X. Is there some way I could combine the ease and power of upgrade but not attempt (and fail) at upgrading core modules? Thank you.
Don't use the system perl. Install your own and start from that. Even when there isn't an ancient perl.
You will have to exclude not just core modules, but also distributions that depend on newer versions of core modules, and distributions that depend on those distributions...
It's a battle you can't win and shouldn't even try to.
BTW, the CPAN-trying-to-upgrade-perl bug was really really ancient; are you really seeing it?
Related
I've done some research and it seems like ActivePerl had issues with earlier releases of it's product with certain CPAN modules not installing properly. However, I'm running the 5.14.x version and I've not had any problems.
According to some quotes I've seen:
ActivePerl is 100% compatible with the reference distribution of Perl.
Code tested with ActivePerl will run on any Perl installation that has the appropriate extensions installed.
I assume that the first statement refers to the standard modules you get with the Perl installation and for the second, I'm not sure what they are saying?
In any event, is there any way to find out how compatible ActivePerl is with the current CPAN modules or is that something that isn't known? I just don't want to spend time with it, only to have to switch to something like Strawberry Perl next month to avoid CPAN module build failures for the more common modules.
If ActivePerl is compatible with say 80% or higher with the CPAN modules I would feel more comfortable about using it, but I couldn't find any information on this.
I doubt a generic statistic will be that useful. In general I would expect all "pure perl" modules should work more or less out of the box. Keep in mind however that certain perl modules really are interfaces to lower level linux/unix style shared libraries (dlls in Windows terms), where availability is less certain. In my experience (having written a few perl applications being hosted on Windows, against my advice) most things will work, and/or are fairly easy to work around, and both ActiveState and Strawberryperl seem to have decent support for most common modules.
The first statement doesn't refer to modules at all. It says that ActivePerl is not based on Perl, it is Perl. As such, anything that will run on Perl will also run on ActivePerl.
This also means that all modules on CPAN are compatible with ActivePerl since ActivePerl is Perl.
Whether a module is compatible with Windows is an entirely different question, and it can only be answered on a module-by-module basis.
The second statement points out that if you had a script or module that runs on a pristine ActivePerl, it might not necessarily run on a pristine Perl because ActiveState includes modules in its distribution that aren't core modules (e.g. LWP). But all you'd need to do to make the script or module run on the other distribution is to install those modules.
You can check on the availability of PPM modules at http://code.activestate.com/ppm/. For example, one module that doesn't work well through PPM is PAR::Packer.
I'm have Perl 5.8 installed on all of our servers and wanted to use the DBI and DBD::Oracle modules to access our databases. My main concern is with the newer versions of perl the DBI and DBD modules will stop working with 5.8. Then I'd have to upgrade every server to the newest perl version.
My question is as perl itself becomes later versions and modules are developed for them will they still be backwards compatible? "CPAN does not carry all ancient releases and patchlevels of Perl", if I create documentation saying run "cpan -i DBI" if the newest version of DBI will not function with 5.8?
There is no guarantee.
In general, you want to use the same versions of the modules on all your systems. If you use different versions then you will have different bugs and features available on different servers.
I'd suggest creating Debs / RPMS / etc for the ones you are going to use and then run a package repository that all your servers share.
Not absolutely, but in general perl is pretty gentle about breaking code, with not many breaking changes, and long deprecation cycles on the ones that do happen. A pretty hefty portion of the code that was uploaded to CPAN in 1999 will run without modification in perl 5.14.
Since perl 5.12, the perl release cycle has become shorter, and the deprecation periods have also become shorter, which is cause for concern, but at the same time the concept of feature versioning has gained currency. The idea is that code may declare the version of perl that it's targeting with use VERSION (e.g. use 5.16.0), and any code that doesn't declare a version is assumed to be targeting approximately 5.10. When code that targets an older perl version is run on a newer perl version, newer features that might cause compatibility issues (e.g. new keywords) are disabled, and old misfeatures may be re-enabled in the name of compatibility. This isn't an absolute guarantee, but it will be adhered to as much as practical.
More information about back-compatibility and deprecation is in perlpolicy.
In general, no. There are a lot of great new features in recent releases of Perl (smart match operator, the // operator, for two one example) that are not backwards compatible. Many authors will decide to take advantage of these features rather than keep their modules compatible with older versions of Perl.
Check the CPAN Tester's Matrix of a module, including the link about the max version that passes all of the distribution's tests, to get an idea of what versions of Perl are compatible with each version of a module.
cpan -i Some::Module will indeed attempt to install the latest version of the module Some::Module, but with a little research, it can be used to install older versions too. You need to find or guess the author of an older version and provide the path to the distribution on the CPAN mirror servers. For example,
cpan -i J/JF/JFRIEDL/Yahoo-Search-1.9.12.tar.gz
cpan -i A/AS/ASG/List-Gen-0.80.tar.gz
CPAN authors may delete their older distributions from CPAN. But even then, the distribution is available at the BackPAN if you're willing to download, unpack, and build the distribution yourself.
What is a "dual-life" module? It's mentioned in the perldelta for Perl 5.14.
Dual life modules are modules that exist in two disconnected source repositories, commonly meaning both in the Perl core (those libraries distributed with perl), and on CPAN.
The CPAN version may be updated more frequently than the core version. The core version may have been tested on more platforms.
In the context of the link you gave, "adding as a dual-life module" means forking the CPAN distribution, possibly making some changes (such as normalizing documentation or licensing), and incorporating that fork into the core perl repository. This means that this module will now be installed by default when anyone installs this version of perl.
A dual-lived module is one that is found both in the perl distribution and in its own distribution (on CPAN). For example, Data::Dumper is part of the perl distribution and the Data-Dumper distribution. On the other hand, IPC::Open3 is only available as part of the perl distribution, so it's not dual-lived.
The advantage of a dual-lived module (these and these) is that it can be upgraded without upgrading Perl.
If you wanted to upgrade a core module that isn't dual-lived (these), then you have to upgrade all of Perl.
cpan fails with this weird error as follows
Error: Unable to locate installed Perl libraries or Perl source code.
It is recommended that you install perl in a standard location before
building extensions. Some precompiled versions of perl do not contain
these header files, so you cannot build extensions. In such a case,
please build and install your perl from a fresh perl distribution. It
usually solves this kind of problem.
(You get this message, because MakeMaker could not find "D:\fbl_esc_bcd_tb\tools\perl\lib\CORE\perl.h")
Running make test
Make had some problems, maybe interrupted? Won't test
Running make install
Make had some problems, maybe interrupted? Won't install
Problem is I can't install new active perl versions in this environment and the tool I want to coverage on does not run outside this environment.
Short answer: The ActiveState PPM repository has a precompiled version of Devel::Cover you should be able to install.
Long answer: That's not a normal message from MakeMaker so I'm willing to guess its an ActiveState addition, but its probably true. The problem is exactly what the error message says; your distribution is missing some important files, specifically the C header files for Perl, so it cannot compile C code necessary for modules like Devel::Cover. This is often the result of an overzealous sysadmin or packager looking to save a few dozen K of disk space. You could probably take the header files from the 5.8.7 source, copy them into the CORE directory and it will probably work. It won't make anything worse.
I agree with Evan that, assuming this is a Windows machine, you should switch to Strawberry Perl which plays much better with the rest of the Perl community than ActivePerl.
Otherwise, ActiveState is a commercial company and they have paid Perl support. Give them a ring.
Active Perl does not use CPAN. If you want to use CPAN use Strawberry Perl. Active Perl uses binary distribution through its ppm system. There are a few third party repos for it if the official one doesn't have Devel::Cover -- though the official probably has Devel::Cover.
Most people these days are moving to Strawberry and away from AS. In my opinion, it is far more stable and CPAN-friendly, and surely less proprietary. Also, expect to be able to get stable versions of most everything - AS has been known to lag years in many occasions in the official repos. strawberry also comes with its own compiler and build environment so you can even get ::XS versions working with ease.
I'm testing my project installation script on CentOS5.5.
My project need Date::Manip module which requires feature module...
When I try to install it (feature) through CPAN, CPAN wants to install Perl 5.9.5...
*** WHOA THERE!!! ***
This is an UNSTABLE DEVELOPMENT release.
The version of this perl5 distribution is 9, that is, odd,
(as opposed to even) and that signifies a development release.
If you want a maintenance release, you want an even-numbered version.
Do ***NOT*** install this into production use.
Data corruption and crashes are possible.
It is most seriously suggested that you do not continue any further
unless you want to help in developing and debugging Perl.
If you *still* want to build perl, you can answer 'y' now,
or pass -Dusedevel to Configure.
How can I handle this kind of problem ?
Date::Manip requires Perl 5.10 to function, see the META.yml:
requires:
...
perl: 5.010
The older version (5.56) instead only requires perl 5.001 to function and should therefore be safe for you to install.
In other words, if you want that latest version you'll have to update your system's perl to at least 5.10. CentOS comes with an old 5.8.8 version, unfortunately.
use feature is a Perl pragma that was first introduced in the 5.10 stable release.
This probably means that Date::Manip requires Perl 5.10.
CPAN is wrong here, don't let it install a development Perl release.
In your specific situation, you can of course go with Perl 5.10 which is the stable version next after 5.9.
In generic situation when there's no later stable version, first you should try to see if the module you want has an older version compatible with your Perl version.
If not, it's a risk/reward trade-off. In a production environment, I'd personally tend to avoid any development branches, unless the success of a critical project hindges on just the module you need AND you can't use another module or roll your own. So far, I never encountered a situation - and can't even concieve of a plausible one - where there's no workaround.
#sebthebert if you want CPAN.pm to only try to install modules that are known to work with your version of perl, see http://cpxxxan.barnyard.co.uk/.
The Centos project provides a version of Date::Manip that works with their version of Perl. It's pre-packaged to work with yum. Currently that seems to be Date::Manip version 5.44 (which predates the requirement for Perl 5.10).
$ sudo yum install perl-Date-Manip
As an aside, are you sure you want to use Date::Manip? DateTime is usually a better choice.