The following is probably not the kind of procedure one would follow in a well organized environment.
I, on the other hand, have a handful of computers, each of which has a bunch of perl
s installed. Most of those might be activated (via perlbrew once in a while. That means, I sometimes find that I need to make sure everything is up-to-date before checking a bunch of things.
Now, with ActivePerl, you get ppm, and it is pretty convenient.
But then, on the same laptop, I also have a couple of Strawberry Perl distributions, as well as perl
s I built from scratch using the free Microsoft compilers.
Then, we have the Mac, with the various perl
s installed via MacPorts, and, also, via perlbrew
. Then, there are two netbooks with ArchLinux on them, the dual boot partition on my main laptop.
I think you get the picture. Nothing is mission critical. Each Perl distribution has a bunch of modules I installed using cpanm at some point.
I’d rather try to upgrade all the modules/distributions I have for one specific perl
at once: If anything is messed up, I am not averse to nuking that perl
and everything that came with it, and starting from scratch. It hasn’t happened yet, but if it does, I doubt I’ll spend more time dealing with that than I would have fiddling with all the individual environments in turn.
Most of the time, I can just type a couple of commands and leave:
$ cpanm --self-upgrade
$ cpan-outdated |cpanm
If you want to inspect the CHANGES
for everything that is outdated, you can use cpan-outdated |cpan-listchanges
(hat tip Daniel Lavelle who seems to be much more disciplined about the whole thing ;-)
cpan-outdated
and cpan-listchanges are helpful on their own, even if you don’t go the “not a care in the world” route of cpan-outdated |cpanm
.