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
Related
I have a clean install of perl 5.26.3, and I am trying to install Dancer2.
Dancer2 depends on App::Cmd::Setup, which depends on Getopt::Long::Descriptive, which depends on Params::Validate, which depends on Devel::Peek.
Looking at Devel::Peek on MetaCPAN, it is part of the perl 5.30.2 distribution, and I can not find the Devel::Peek package by itself. The "Jump to version" list on the Devel::Peek page lists previous version of perl, not of Devel::Peek.
Installing Dancer2 on perl 5.26.3 apparently has a hard, transitive dependency of installing perl 5.30.2, but I do not have the authority -- nor any desire -- to update the perl installation.
Is there a version of Devel::Peek available by itself?
Thank you.
Edit
It looks like I have a broken perl installation. I have no Data/Peek.pm anywhere on the filesystem. When I try to use Devel::Peek, I am told Can't locate Devel/Peek.pm in #INC.
I'll install from scratch and start over.
You should be able to fix it with the installation of
yum perl-Devel-Peek
For alpine, be sure to do apk add perl-dev to add additional modules needed to build some packages.
No. It's only available as part of Perl. It's has been part of Perl since 5.6 in 2000.
As such, if you don't have Devel::Peek, you have a broken or partial Perl installation. But this is actually quite common, since many package managers break down Perl into different packages. For example, RHEL split off Devel::Peek into the perl-Devel-Peek package. So if we're talking about a Perl managed by a package manager, check the package manager for the missing bits.
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
While loading necessities into my crouton, apt-get recommended that I install libtemplate-perl. This seemed a jolly idea, and I obeyed.
Reading this answer, I see a fellow traveler install Plack and Starman via CPAN, but then use apt-get to install Dancer.
Minutes before reading said answer, I had installed Dancer via CPAN. And it had worked. It had worked real good!
What happens differently when I install a CPAN package via a non-CPAN package manager? Are there pitfalls I need to be wary of because my libtemplate-perl came from apt-get, or my Dancer came from CPAN?
On Debian or Debian based distros like Ubuntu, CPAN (/usr/bin/cpan utility) installs modules into /usr/local/lib/ by default. And Debian packages keep their files in /usr/share/perl5/ and /usr/lib/perl5/.
It's a better way to choose dh-make-perl tool to package any CPAN distribution not available in your apt repositories, to avoid making mess (serious risk of conflict between apt and CPAN):
dh-make-perl --build --cpan Some::Module
dpkg -i some-module*.deb
Also check out about local::lib and perlbrew.
A lot of tutorials, Stack Overflow answers, walk throughs, etc. will not want to assume that you know how to use /usr/bin/cpan and will instead suggest that you use your system's package manager, which you are more likely to be familiar with.
This is especially true if you are using a tool written in a particular language, but you don't know that language. For example many people wouldn't care whether crouton is written in Perl, Python or Lisp, they just want a tool they can use. Your average Debian or Ubuntu user is more likely to be familiar with apt-get than with cpan.
If you are looking to program in Perl I recommend installing things by cpan, using perlbrew and/or local::lib. If you are just looking to install a tool you can use, I would recommend using apt-get.
Additionally apt-get has the advantage that non-Perl dependencies will be installed automatically. For example the CPAN module XML::LibXML requires that the libxml2 headers are available on the system; the CPAN distribution has no way of stating that as a dependency, and will simply fail on install if it can find the headers to link against. The Debian package can actually specify that libxml2 is a dependency, and will install the dependency automatically for you.
Despite that if you are looking to use XML::LibXML as a Perl programmer, I would recommend installing it with cpan and installing the libxml2 package via apt-get. Having all your Perl modules installed in the same place - again, via perlbrew or local::lib - will help you keep your sanity in the future. CPAN is preferable to apt-get in this case because not all distributions have been packaged for Debian, and so you get a lot more options if you use CPAN directly.
In summary: TIMTOWTDI ;-)
Another difference to mention that I don't see in other answers, is that if you use CPAN to install a module then the module version you get will be set, until you decide to upgrade that module. Whereas, if you use apt and a later version appears in Debian at some point in the future, then apt-get upgrade will update it.
Maybe you want that, maybe you don't. It's neither necessarily an advantage, nor a disadvantage. Simply a difference to be noted.
The good things about apt-get are
that you can uninstall the packages afterwards should you need to
if you are maintaining any number of servers it is quicker to use apt-get as there is no building required
there are definite versions of packages which are tested for compatibility
The downsides are
not necessarily the latest version of packages
not all packages are available
apt-get installs are generally easier and better than cpan because of dependencies alone.
If you are so lucky as to need SOAP::Lite, for example, it is many dozens of dependencies, and a one-line "apt-get install libsoap-lite-perl".
It is sometimes not clear how Perl CPAN names map to their repository package names, but "apt-cache search " is your friend.
Another approach, that can be used for any distro in HOME install as simple user:
Pros
avoid conflicts
up to date version of perl and modules
when you reinstall, you keep your home/perl as-si
you can upgrade all installed modules with $ cpan -r
Cons
you need to upgrade Perl manually
How to
Edit ~/.bashrc or such, and add:
export PERL5LIB=~/localperl/lib/
export PATH=~/localperl/bin:$PATH
Then
source ~/.bashrc
Install latest Perl5 from sources: https://www.cpan.org/src/README.html
Now, you have an isolate Perl installation in your home.
Enjoy the power to install any libs via:
$ cpan -i Whatever::Module
I was using ubuntu 12.04 until 12.10 was released. I used ubuntu for software development and after installing 12.10, i noticed that the perl version (5.14) shipped with 12.10 does not include the Switch.pm module needed while building WebKiT-GTK.
Looking around on the internet i found few suggestions indicating that i should install something call p5-switch from something called ports. I have looked around and was not able to get this done. I am not a perl guy and have no idea where i can get this package.
Can someone please help me as to
1. Where to download the package for ubuntu 12.10
2. In case it is not a .deb, How do i install it.
OR
1. At least be able to downgrade the perl installation to something lower than 5.14
Thanks and Regards
~Sameer
sudo apt-get install libswitch-perl
will install it for you.
"ports" is a *BSD packaging system of sorts, not what you should be looking for.
You can find what package has a particular perl module by going to packages.ubuntu.com, entering Module/Name.pm (in this case, Switch.pm) in the "Search the contents of packages" form and checking "packages that contain files whose names end with the keyword" and selecting the desired distribution, then making sure you ignore false hits like CGI/Switch.pm in the results. Debian has the identical search for its packages at packages.debian.org.
(Note that Switch.pm has serious limitations, was never really intended to be used in production, and should certainly not be used in new code.)
Do make sure you've checked properly that there isn't the Switch module available via apt. If it is available, that's the one you want.
No, then you've two options the longer, correct way and a shorter way that's not quite as clean.
1. Longer
Install cpanm and perlbrew with apt. The perlbrew tool lets you install a complete version of Perl from scratch in a separate directory. Set up a user for your webkit building, run perlbrew as that user, install your perl. Then, use cpanm to install required modules and you are done. A bit of googling will get you step-by-step examples of how to use these tools. If anything goes badly wrong, you can just delete all the files in that user's home directory and start again - all you waste is a little time.
The reason experienced Perl people prefer this is that it keeps the perl you want for webkit-gtk separate from your system perl that ubuntu's packages will expect to be unchanged from the one they ship.
2. Shorter
Install cpanm with apt. As root, run "cpanm Switch" and it will install the Switch.pm package and any dependencies. It will also upgrade any already installed packages it thinks it needs to. This last step is why this option isn't ideal. In the (rare) case when the update isn't compatible with something else on your system uninstalling is fiddly.