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/).
Related
Is there a standard way to upgrade to a new, minor version (and binary compatible) of Perl without a full recompile from source?
For example, if I have Perl v5.24.0 installed with a bunch of CPAN modules, can I upgrade this installation to v5.24.1 without recompiling a whole new build and doing the same for all of the CPAN modules installed under v5.24.0? Or do I have to create a list of all installed CPAN modules, compile a new Perl, and reinstall those CPAN modules using the newly compiled version?
I'm not seeing an easy way to "patch" the current system, using the source code from the latest release. (Note: I'm wondering if there is a native way to do this (i.e., not using perlbrew)).
if I have Perl v5.24.0 installed with a bunch of CPAN modules, can I upgrade this installation to v5.24.1 without recompiling a whole new build
As far as I know, no. You have to configure/compile/install the new perl from scratch.
and doing the same for all of the CPAN modules installed under v5.24.0?
Yes: Configure asks you about existing perl versions and whether it should include their directories in #INC. If you say yes (which I believe is the default), all already installed modules are available in your new perl.
That said:
Or do I have to create a list of all installed CPAN modules
This is easy with cpan -a:
$ cpan -a
... lots of modules listed here ...
Wrote bundle file
/home/user/.cpan/Bundle/Snapshot_2017_04_25_00.pm
and reinstall those CPAN modules using the newly compiled version?
After installing the new Perl, run
$ cpan Bundle::Snapshot_2017_04_25_00
(or whatever name cpan -a gave the snapshot file in the previous step) and it should install everything you had before.
If you are using perlbrew it has an 'upgrade-perl' command. The downside is that the initial configure parameters still aren't passed to the newly built version.
See also http://www.modernperlbooks.com/mt/2013/03/upgrade-in-place-with-perlbrew.html
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
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am an old time Perl hacker but I have basically given up on my Mac because I usually can't install anything with cpan.
Something in the dependency list usually fails with meaningless (to me) errors. My Mac is new but has a long history copied over during upgrades from previous Macs for over 10 years.
Over the years I have tried to use fink, MacPorts and homebrew and I suspect by this time I have many incompatibilities.
Before I post my latest problem what I would really like to do is start clean with Perl as if I had a clean OSX-lion install. Is there any way to do this without wiping my disk and installing OSX from scratch?
None of the projects you mentioned installs into system directories. So, removing them from your current user environment should be as trivial as taking them out of your path, and removing references to them from your startup files (e.g., .bashrc, or if you added them to your "login items" etc).
After that, you'd be left with what the OS gives you. LEAVE THAT ALONE. Install perlbrew (so you can install multiple perls and switch among them without disturbing the rest of the system) and cpanm (cause it's more funner ;-) and take it from there.
Make sure to read the documentation for everything you use so you understand what they do and how they do it.
PS: If you did force any of fink, ports, or homebrew trample on system directories for some reason, you did it wrong. If I were you, I would choose to install from scratch in such a case (but make sure to back up your documents first). I personally think even /usr/local as homebrew developers advocate is not a good idea, but if you did that, at least they give you an uninstall script.
OS X and Perl = pain a bit, when want many modules.
Problems:
macports - default 5.12 optional 5.14. Unfortunately many macports has wrong dependencies, asking exactly 5.12 and when you have 5.14 running into problems Your default perl will be 5.14 and some packages will install and use 5.12 :(.
perlbrew - very good and easy but here is a drawback. When you want install some packages with macports and what are depend on macport's perl - it's get installed. So you will get one macport's perl (what will works with installed package and perlbrew perl). And what is worse, your e.g. 5.14 perlbrew will not play correctly with macports (default 5.12). E.g. p5-GD, ImageMagick and many many others.
homebrew - IMO, horrible. Stopped reading the doc when reach a section recommending rm -rf /usr/local. (of course, with all data, e.g. mysql). Maybe now it is better.
fink, same problems as macports.
My solution:
simple using macports version for real development and perlbrew only for testing (but not with dependent binaries, like GD and so on). When want "perlbrew" sourcing its shell-start-files, otherwise not and using macports.
Another source of pain is - trying install macports version of perl modules first (because of consistency and dependency) and only when macports version is not exists, or need the newest cpan version - installing it with cpanm. CPAN version Extutils::Makemaker does not like macports version - and recompiling it all times when installing modules with cpanm.
Real pain. Macports badly need a new perl - maintenaier, who will clean up wrong dependencies and make the macports version of cpanm what will install cpan version of modules correctly as macport packages. Something has FreeBSD has years ago - cpan modules comes into BSDPAN bundles what are manageable with pkg_* commands.
So the result: I'm currently don't known any easy OS X perl usage. immediately when you want use some perl-dependent software you will must compile them itself (and sometimes they will not compile - so you need the patched version for OSX, so start uses macports or homebrew and ... pain.. ;(
As Sinan already told - any of those installations does not interfere with your system perl, but you probably started using cpan first with system perl and installed some modules into /Library..
IMO, you can live with it. Simply install macports and start using it. But if you want some perl-repair-installation - probably the better place to ask is at: https://apple.stackexchange.com/ .
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.
I upgraded to Ubuntu Intrepid Ibex yesterday and suddenly some of the Perl modules that I installed (on the Hardy Heron) have all gone missing!
I get the usual "Can't locate module in #INC" error. Has any of the CPAN repositories changed or something for Intrepid? Google doesn't help at all.
Thanks in advance.
The standard solution is to generate an "autobundle" with CPAN.pm before upgrading Perl. A search for autobundle yields links to a handful of existing SO questions discussing Perl module management and several that look like they should provide more information. The CPAN.pm manual touches on autobundle, but doesn't include much detail.
Since you've already upgraded Perl, one solution for installing your modules would be to generate an autobundle file and use the entries in the generated file as a guide to write a custom autobundle file with entries for your modules (only). The autobundle file format is just POD, so this should be easy to do.
In the future you should probably make it a habit to generate an autobundle before upgrading Perl. This is not a perfect solution, the autobundle will include entries for core modules that will have to be removed before actually building from it, but at least you'll have a snapshot of installed Perl modules so that you can get your Perl install fixed up after an upgrade.
Your Perl installation has changed from version 5.8 to 5.10. Since many of the modules you want are in perl-version-specific directories, you may want to re-install using the CPAN tools (e.g. the cpan command).
But since you're using Ubuntu, please keep in mind that many many CPAN libraries are also distributed through the Ubuntu package manager, and the CPAN packages install into a different place than Ubuntu installs them (this is transparent to the user, since both are in the #INC paths).
I recommend using the Ubuntu packages when they're available, because they will be updated by the package manager (APT) when new ones are released on the central package servers. The name format is slightly different. Here are two ways to install the same package, from different sources:
$ cpan List::MoreUtils # installs latest from CPAN
$ sudo apt-get install liblist-moreutils-perl # installs latest from Ubuntu universe
the advantage of the latter is that it will be updated by sudo apt-get update.
Perl changed on Intrepid.
Before upgrading, you had Perl 5.8, now you have 5.10.
Probably /usr/lib/perl5/5.10.* is used instead of /usr/lib/perl5/5.8.8 since the Perl version has changed