I use cpanminus to install Perl packages to userspace, but i have not found idiomatic way to maintain packages afterwards. How you update, delete (with dependencies) and get overview of listed packages?
You can use cpan-outdated. The man page has clear instructions for how to use with cpanminus.
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.
I have perl 5.10.1 on my server but I need a higher version of perl than that. I do not have privileges to modify this version so I installed the latest one on my home directory. How do I specify unix to preferentially use the newer version?
The simplest answer is to use perlbrew. This is a tool to install and manage multiple Perl installations in your home directory. You can switch between which one is active.
Follow the instructions on their page to install perlbrew, and then install the latest stable Perl with...
perlbrew install stable
Then tell perlbrew that's the Perl you want to use with...
perlbrew switch stable
If you want to install more modules, use cpanm to install modules to the currently active perl.
cpanm Acme::Pony
If you don't want to use perlbrew, you need to mess with your PATH environment variable. This is a list of directories your shell will search through when finding a program to run. You'd need to put /path/to/where/you/installed/perl/bin at the front. More on this in this article.
I highly recommend you use perlbrew. It takes care of all this for you.
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 installed some Perl modules in my Linux machine. If I enter perldoc perllocal it shows a list of Perl modules installed in my machine, but now I don't need those Perl modules, so I want to remove them.
Does anyone know how to uninstall or remove those modules installed in Linux (debian 2.6.26)?
The Perl installers are just that... installers. They don't verify that they're not overwriting existing files, and they don't record precisely what they install. Therefore, they cannot uninstall. If you want a proper packaging system, you can't use the Perl installers.
If you use CPANPLUS to install a module, you can (at least in theory) also use it to uninstall it:
$ cpanp
...
> u Unwanted::Module
...
> q
$
The older CPAN module does not support an uninstall option. And, as Randal Schwartz notes, uninstalling modules is not always reliable.
Use cpanp (its uninstall is not limited to cpanplus-installed modules), or see ExtUtils::Packlist's modrm example.
Uninstall tools have historically been not readily provided because the install process is not robustly reversible, as Randal cautions.
As I've mentioned somewhere else on SO, my answer is to just leave them. There are VERY few Perl modules large enough to take up any actual space on you system. I'm not saying don't try if you really need the space, but if you don't ... its not worth it.
You can try App::pmuninstall
DESCRIPTION
App::pmuninstall is a fast module uninstaller. delete files from
.packlist.
App::cpanminus and, App::cpanoutdated with a high affinity.
I tried cpanp uninstall and it didn't work for me. I did find success using App::pmuninstall.
pm-uninstall [options] Module ...
pm-uninstall - Uninstall modules - metacpan.org
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