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.
Related
we are using perlbrew for maintaining the various version of perl.
Along , now we are facing challenges as we need to update the scripts to the latest CPAN module. But we want still some the script to keep make use of old perl module till the compatibility issue is resolved.
Is there any away to install the lastest version of module with impacting the older version
perlbrew keeps each version separate, include its CPAN modules. If you run:
perl -E'say for #INC'
you will see the Perl version in the paths. If you switch the Perl, you will see different paths for #INC.
You can still use PERL5LIB with perlbrew-installed perl. But since you're already using perlbrew, why not just install a second build of that version of Perl for use with your newer scripts? Upgrading modules for one perl install won't affect others.
In some environments, Carton maybe the tool you are looking for. It requires a cpanfile where the dependencies are specified, so each script should be handled as an independent application in order to isolate each of them
I have on UNIX SunOS 5.9 Generic_122300-61 sun4u sparc SUNW,Sun-Fire-V240 perl v5.6.1, but I want to install the newest version.
Can I install the newest version and have it together with oldest but on different directories?
But my questions is :
now I have perl home on /bin/perl.
The newest perl version will be on different home directory? And also cpan and modules, are they going to be installed?
Since you are on Solaris, don't mess with the Perl that comes with the operating system. It's used by the OS itself, and if you change it things can get weird.
That said, you can absolutely install other Perl versions in parallel with it. If you're compiling manually, all you need to do is to give the flag -Dprefix=/some/nice/directory to the Configure script. Once it's compiled and installed, you only need to put /some/nice/directory/bin earlier in your PATH than /usr/bin.
If you want a system-wide installation of a newer Perl, I'd suggest picking the latest version (currently 5.20.0, but 5.20.1 is at RC2 so it should be out soon) and installing it in /usr/local. If you want a newer Perl for your own personal use, I'd strongly suggest making sure you have enough of an environment that Perl can be compiled, and then install and use perlbrew (http://perlbrew.pl/).
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.
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?
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.