I downloaded the 5.12.3 installer to upgrade my 5.12.1 installation. After installing 5.12.3, my previously installed cpan modules are gone. Is this expected behavior? Should I be backing up my library before upgrading to prevent this?
I would claim that this should not be expected behavior.
The site directories are not part of the standard distribution and should not be touched by the distribution. Heck, it's even why the site directories even exist. Otherwise, why not simply download all of the modules to the same directory? Why make a distinction between the standard Perl modules and the modules you download from CPAN?
I too found this out the hard way when my personal modules -- modules that are not part of CPAN -- were blown away by my upgrade of Strawberry Perl. ActivePerl does it right -- not only not touching the site directory, but also adds in the Perl version to the standard module directory and the site directory.
It is expected behavior. Next time you can use "autobundle" feature of CPAN client, it will create list/bundle of modules to reinstall using CPAN client in new version.
Related
I have seen some issues with CGI version being updated to v4.51 in CentOS 6.8 machine. I can check the version of CGI using:
perl -MCGI -e 'print $CGI::VERSION ."\n";'
But, I am more interested in knowing when was it updated and by whom, since automatic update of modules is disabled on the system. There could be other Perl modules or CentOS libraries also that might got affected. How can I figure out what has happened, when and by whom?
Other than looking at file attributes, there's nothing that the cpan clients do to log how it did what when.
This is one of the reasons that I encourage people to keep a project directory for CPAN modules (perhaps with local::lib) so they can control the versions of the modules they depend on without disturbing other projects. There are other solutions, such as Pinto, that attempt to manage this too.
A comment already notes that the cpan clients will update modules and their dependencies to the latest versions of things on CPAN. If CGI was the dependency of another update, it may have been implicitly updated.
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
I am creating a custom module to be placed in the directory /usr/local/cpanel/Cpanel. My perl module requires SOAP::Lite. Since the scripts placed in the directory /usr/local/cpanel/Cpanel are run under cpanel's internal perl version 5.6.2, does on install the SOAP::Lite module?
Trying to build the module with cpanel's build tool fails as another perl module is require to build the source module for soap::lite from cpan.
Perl modules are usually installed using the cpan program that comes with Perl. This checks all the dependencies for you and installs everything you need. This is what you should do.
If you don't have the ability to access and run this program, then you may not have permission to install modules at all. Possibly you could get whoever is running your system to do it for you (also ask them to upgrade your nearly 9 year old version of Perl while they are at it!).
Beyond that, there are not many options. You could try building the required modules on another, similar system and copying over--if you enjoy pain.
I want to send emails using gmail's smtp servers and perl. I am trying to install Email::Send::Gmail, but it is not clear to me what are the steps to install it. It seems that it depends on other modules that I do not have installed.
This is partially dependent on which distribution of Perl you're using.
ActivePerl includes a utility called PPM (Perl Package Manager) for installing modules. It handles dependency resolution automatically. PPM is particularly nice for installing XS modules on Windows where a compiler isn't typically available. The downside to PPM is that it some CPAN modules aren't available (probably because they fail ActiveState's automated build process). You can run PPM from either the start menu or by typing ppm at a command prompt.
A more general option is to use the interactive CPAN shell. Note that you must have a compiler to install XS modules using this method. You can access the cpan shell by typing cpan at a command prompt.
The brute-force approach of last resort is to download tarballs from CPAN and manually install them one at a time. When an install aborts due to unsatisfied dependencies download and install them then go back to the first module and try again.
Type:
cpan Email::Send::Gmail
… at the command prompt.
It's probably a good idea to set up local::lib first.
Or see the Perl Foundation Wiki on installing CPAN modules or the same but without root access.
Or see the CPAN guide to installing modules.
If you are using ActivePerl, try the PPM (Perl Package Manager) tool that comes with ActivePerl first. When you tell it to install a module, it should handle all of the dependencies for you.
Note the dependency tree for Email::Send::Gmail. Some of those modules require additional installation of third party software, most notably OpenSSL, which cpan won't do for you.
You can probably install it with:
perl -MCPAN -e shell
install Email-Send-Gmail
Hope it helps,
/Klaus
If you can, CPAN. (ha! It rhymes ... what a crime. Oops, did it again! When will this end... :p) It's essentially the way to install modules for your system. It automatically detects dependencies, downloads, installs, and tests them all for you, and backs out if ever a build or test fails. It's a fantastic and reliable way of installing modules. This works great if you're using essentially any Perl distribution besides ActiveState's distribution, including Strawberry Perl. Generally, this is done with
cpan Module::Name
or, in an interactive mode,
$ cpan
cpan > install Module::Name
If you're using ActiveState Perl, then you probably want to use ActiveState's PPM (Perl Package Manager). It's similar to CPAN, except everything comes prebuilt for ActiveState Perl. ActiveState has a document on how to use their Perl Package Manager on their website, including a graphical example.
If the easy options fail, you are not out of luck. There's some more complex, but manual methods you can do to still install the module.
Most modules that you can download will have within them a bit of metadata in a .yaml file; this will help you figure out whether or not you have all your dependencies. CPAN and PPM automatically resolve and install all your dependencies, but doing it manually will not, leaving that task up to you.
Assuming you have all your dependencies, and you need to install it manually, look for one of two files: Makefile.PL or Build.PL. If you have a Makefile.PL, cd to the directory you extraced the module within a command prompt, and type:
perl Makefile.PL
make
make test
make install
You will need a 'make' program on your system. If it's ActiveState Perl, you may need to install the module manually (see a paragraph or two down.)
If it happens to have a Build.PL, then you need to do a slightly different set of steps:
perl Build.PL
Build
Build test
Build install
(Of course, you may want to consider not installing if make/Build test fails, but that's up to you.)
As a final alternative, if your module has no xs files (ie, code that needs to be compiled on install), and all dependencies are met, you can simply move the files in the lib folder to your perl installation's site\lib folder. If you're interested in just using it for one project, you can add a PERL5LIB environmental variable, pointing to a new, custom library directory (eg, /my/project/lib) and then before running your tool, make sure the environment is set up.
As a followup, see PerlFaq8 - How do I install a module from CPAN.
Also, see PerlFaq8 - How do I keep my own module/library directory?.
Mixing installation methods is asking for heartache and headaches you don't need.
Don't use CPAN with Active Perl. Use PPM.*
PPM download sources can be found at Randy Kobes' site.
If you can't find a PPM of a module you need, you can build your own PPMs easily with Mr. Kobes make_ppm.
You can download a distribution and simply run make_ppm to build a PPM, but I prefer to do the a more "normal" build process:
perl Makefile.PL
make
make test
make_ppm
*If you install your files outside of c:/perl/site/* then it's OK to use CPAN. Just don't co-mingle CPAN shell modules with PPM modules.
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