A mess with different Perl installs - linux

I tried to upgrade Perl and put my computer into a complete mess
I am currently running RHEL6.5, 64bits, and this is the thing:
I had perl-5.10.1 installed, and working nice. this came installed,
and I could see it from yum
I wanted to install Padre, an Perl IDE, but that required at least v5.11 [I was so close! :( ]
There were no newer version for Perl in the repos that I have access to (and I have a limitation that I can't add new repos)
I got approval from my boss to download perl-5.20 .0 from www.perl.org and tried to install it
... and the mess begins!
First I installed the new perl with my own id, and that pushed perl to somewhere under my home dir
I tested with 'perl -v' and could see that my env was pointing to the newer install, however, yum never recognized it (not really a problem)
When I tried to install Padre, seems somehow it had the hardcoded the original perl (from /usr/bin) and still claiming for something as newer as 5.11.
Trying to fix it, I did installed the new perl again, now using root, to make it push perl under /usr tree ... it installed, but pushed perl to /usr/local/bin, instead of /usr/bin
So again, I had one more perl install but Padre still looking for the one on /usr/bin
I give up about Padre, and deleted the files related to it, as well as the perl installed on my home dir, however a couple of perl scripts that I had already coded now are throwing errors like:
perl -cw "xmltest.pl" (in directory: /home/myid/scripts/xmltest.pl)
perl: symbol lookup error: /usr/lib64/perl5/auto/Data/Dumper/Dumper.so: undefined symbol: Perl_Istack_sp_ptr
Compilation failed.
... and Data::Dumper in not the only one ... every time I disable one of the modules, another one hangs in the same, or similar way
From what I read about this, seems that this issue is related to modules that were originally installed for one perl version, and are being called by another, however, I already forced the modules that I use to be reinstalled directly from CPAN, and they still failing
Question: How can I, safely, get free from this current perl installs, and perform a new clean install be able to use it w/o these versions conflicts?
My major concern are about the numerous apps that I have that depends on Perl, and I my not broke then on a uninstall
Any help will be much appreciate.

You should:
cleanup
clean (comment out) your ~/.profile from any unwanted paths, and so on
clean any new perl installation from your $HOME (move to safe place for sure)
in short, try return your environment into previous working state
relog, (logout, login)
repair your system perl. Thats mean,
read #Sam Varshavchik's answer
reinstall it from your distribution, using your package manager (5.10).
this step should overwrite the mess you caused.
test it !
don't continue until youre ensured, everything working right as before.
Lesson learned: never overwrite your system perl
learning
read thru perlbrew.pl
repeat previous step once again, especially with the
the homepage
http://perlbrew.pl/Perlbrew-and-Friends.html
https://metacpan.org/pod/App::perlbrew
https://metacpan.org/pod/perlbrew
installing perlbrew
run the installation command \wget -O - http://install.perlbrew.pl | bash
should finished without errors
follow the instructions how to modify your startup file e.g. ~/.profile or such... (you need to add one line to the end)
check your ~/perl5/perlbrew/bin should contain prelbrew and patchperl
relog
setup new perl, run
perlbrew init #init environment
perlbrew available #show what perl you can install
perlbrew install 5.20.0 #will take few minutes - depends on your system speed
perlbrew install-cpanm
perlbrew list #check
perlbrew switch perl-5.20.0 #activate newly installed perl 5.20
Check your installation
in the ~/perl5/perlbrew/bin you should have 3 scripts: prelbrew , patchperl , cpanm
perl -v should return 5.20
type cpanm - should return ~/perl5/perlbrew/bin/cpanm
You're done.
CPAN modules
You can install new modules with cpanm, like:
applications
cpanm cpan-outdated
cpanm App::Ack
cpanm Unicode::Tussle
cpanm Perl::Tidy
cpanm Perl::Critic
collections
cpanm Task::Moose
cpanm Task::Plack
cpanm Task::Unicode
modules
cpanm Path::Tiny
cpanm Try::Tiny
cpanm JSON
cpanm YAML
etc...
Check the ~/perl5/perlbrew/perls/perl-5.20.0/bin/ for new commands
You will need update your own perl script's shebang line to
#!/usr/bin/env perl
I hope don't forget anything, maybe other more experienced perl-gurus will add/edit/correct more.
Anyway, in the reality the steps 5,6,7 are much easier as sounds (by reading this) and could be done in few minutes.

On rpm-based Linux distributions, you should never install system software manually, like this, by trying to compile and build it yourself. RHEL's package management tool, rpm, performs an important function of keeping track of dependencies between packages, and prevent package conflicts.
The errors you showed are precisely the symptoms of a corrupted system Perl installation, and rpm exists precisely to avoid this sort of thing happening. Manually building and installing random tarballs completely bypasses the safety net that rpm provides.
There's no cookie-cutter recipe for recovering from a corrupted system install of a critical system rpm like perl, but in general:
1) run "rpm -q" perl, this will show you the exact version of the perl rpm package that rpm thinks should be installed.
2) go to the RHEL installation media/directory, verify that it contains the same perl-.x86_64.rpm package. If you previously installed RHEL updates, it's possible that you already updated perl, so look for the version that rpm tells you have installed in the RHEL update directory, and verify that you have the correct rpm package.
3) Execute:
rpm -ivh --force perl-<version>.x86_64.rpm
This will reinstall the original perl RPM package that was previously installed. Your problem is not only that you have extra versions of perl installed, but that it's likely that some of your custom perl builds have clobbered the system perl package, and uninstalling them won't help, you have to reinstall the system perl.
4) In RHEL, many perl modules are installed as separate packages. The above process should be used to reinstall every perl rpm package that you have installed. Execute:
rpm -q -a | grep '^perl'
This will give you a list of all Perl packages you have installed. You will need to repeat this procedure for every Perl rpm package.
It's not a 100% guarantee that this will fix everything, there could be other things wrong too, but this is a good first step towards recovery.

What I have done:
From #Sam-Varshavchik answer:
Found the previous perl rpm in my yum cache, and installed ...
rpm -ivh --force perl-<version>.x86_64.rpm
Checked for others "perl*" previously installed packages ... there were +260 so saved it in a file rpm -qa "perl*" > /tmp/perl.pkgs
With +260 packages to install, I realized that do it manually would take too much time, so it was time to put some ksh skills in practice ...
I checked at my yum cache and found ~130 of the +260 packages, so
took out from the list the base perl package (that I already have installed);
for those in the cache, I decided to install then with rpm, in the same way as the base package;
for those that I did not have handy, I used yum, which would download and do the same
of rpm, so ...
CACHE="/var/cache/yum/x86_64"
for perlpkg in $(cat /tmp/perl.pkgs)
do
FILE=$(find $CACHE -name "${perlpkg}.rpm")
if [[ ${FILE} != "" ]] ; then
rpm -ivh --force ${FILE}
else
yum -y reinstall ${perlpkg}
fi
done
From #jm666:
Installed perlbrew (was able to got it from my auth repos, so got it using yum) and using perlbrew, installed 5.20.0 localy
TODO: Didn't got any additional modules and neither Padre yet ... need to learn more about the way perlbrew works and isolate the installed version away from the system perl
Once again, thanks #Sam-Varshavchik and #jm666 for your support ang guidance

Related

Remove perl package completely

I am trying to uninstall the old perl package and install a new package. I used rpm -e to uninstall the old package. I could still see the below files after uninstalling. How can i completely remove the perl package from my server. It runs on OEL 6.10. And when I do "perl -v" , I could see 5.30 version as output, even after uninstalling perl.
/opt/CWx/perl
/opt/CWx/modules/installed/Module-Build-0.4005/inc/Perl
/opt/CWx/modules/installed/Perl-OSType-1.003/blib/lib/Perl
/opt/CWx/modules/installed/Perl-OSType-1.003/blib/lib/auto/Perl
/opt/CWx/modules/installed/Perl-OSType-1.003/blib/arch/auto/Perl
/opt/CWx/modules/installed/Perl-OSType-1.003/lib/Perl
/opt/CWx/modules/Module-Build-0.4208/inc/Perl
/usr/src/kernels/2.6.32-754.11.1.el6.x86_64/tools/perf/scripts/perl
/usr/src/kernels/2.6.32-754.6.3.el6.x86_64/tools/perf/scripts/perl
/usr/src/kernels/2.6.32-754.2.1.el6.x86_64/tools/perf/scripts/perl
/usr/local/share/perl5_old/Perl
/usr/local/bin/perl
If you want to know which package installed a file you can use the command:
rpm -q --whatprovides [filename]
For example, for the first file in your list:
rpm -q --whatprovides /opt/CWx/perl
None of the files you list are in locations which are used by the standard Perl RPM on a RedHat-based system. You will, I expect, find that they are either installed by a completely different package or not installed by a package at all.
And that will also explain why you can still access Perl. Those files include other versions of the Perl compiler and I bet that whoever installed them also changed the PATH so that you have access to at least one of them.
If you want to know which Perl installation is responding to your commands, just run this:
which perl

Cant install Net::SSH2 perl module

I'm trying to install a perl module: Net::SSH2 with cpan but doesn't actually works.
cpan -f install Net::SSH2
Output:
CPAN: Storable loaded ok (v2.20) Going to read
'/root/.cpan/sources/authors/01mailrc.txt.gz'
............................................................................DONE
Going to read '/root/.cpan/sources/modules/02packages.details.txt.gz'
Database was generated on Mon, 22 May 2017 22:29:03 GMT HTTP::Date
not available ............. New CPAN.pm version (v2.16) available.
[Currently running version is v1.9402] You might want to try
install CPAN
reload cpan to both upgrade CPAN.pm and run the new version without leaving the current session.
...............................................................DONE
Going to read '/root/.cpan/sources/modules/03modlist.data.gz' Can't
locate object method "data" via package "CPAN::Modulelist" (perhaps
you forgot to load "CPAN::Modulelist"?) at (eval 16) line 1. at
/usr/share/perl5/CPAN/Index.pm line 518
CPAN::Index::rd_modlist('CPAN::Index', '/root/.cpan/sources/modules/03modlist.data.gz') called at
/usr/share/perl5/CPAN/Index.pm line 85
CPAN::Index::reload('CPAN::Index') called at /usr/share/perl5/CPAN.pm line 955
CPAN::exists('CPAN=HASH(0x21fd2f0)', 'CPAN::Module', 'install') called at /usr/share/perl5/CPAN/Shell.pm line 1243
CPAN::Shell::expandany('CPAN::Shell', 'install') called at /usr/share/perl5/CPAN/Shell.pm line 1639
CPAN::Shell::rematein('CPAN::Shell', 'force', 'install', 'install') called at /usr/share/perl5/CPAN/Shell.pm line 1935
CPAN::Shell::ANON('CPAN::Shell', 'install', 'install') called at /usr/bin/cpan line 318
main::_default('ARRAY(0x1938f18)') called at /usr/bin/cpan line 278
It seems that your installation of CPAN is incomplete or otherwise corrupted. OS and Perl version could be helpful. On many current Linux distributions, Perl modules and their dependencies can be installed using the normal system software utilities like yum (RHEL/CentOS), apt (Debian/Ubuntu) and yast (SuSE). Drawback is that versions may not be the most current.
This PerlMonks thread has someone else with a similar problem. It looks like this answer worked in that case:
It looks to me like you have some corrupt data in your .cpan directory. I'd blow it away and try again:
$ rm -rf /home/user/.cpan
Try it at your own risk. In your case, you would need to delete /root/.cpan.
In addition, the correct use of cpan is to list the module names after the command. So, instead of cpan install Net::SSH2, you should use cpan Net::SSH2. If you use the -f option, you must specify -i: cpan -f -i Net::SSH2, but try without forcing things first. You do not want to willy-nilly install broken modules in the system's perl.
In fact, in general, you do not want to mess with the system's perl at all. Build your own perl and mess with it as much as you want.
PS: install is a dummy module created precisely because many people make this mistake.
The safest and most convenient way to install Perl modules can depend on distribution. For example, the recommended method on Fedora is:
$ sudo dnf install 'perl(Net::SSH2)'
As shown in that example, installing Perl modules on your system usually requires sudo or the root user. So you might want to try your command with sudo if you're a sudoer.
If you don't have that kind of power, you may need to install it locally. That usually means downloading it to a Perl library directory you create in your home directory, and including the path in #INC somehow, such as updating your $PERL5LIB to include the /home/user/perl/modules/Net-SSH2/lib/ or whatever your path to the module lib directory is.

RPM fails to follow dependency order on install

I'm trying to force rpm to follow a given install order and it is not working as expected. The Requires clause I added is not being respected.
I am doing a bare-metal Linux installer (openSUSE 42.2-based). A whole system -- hundreds of packages -- are installed with one RPM command (using --root). I am having problems with three packages -- pam-config, pam-script, and openssh. The pam-config %post scriptlet tries to modify files contained in pam-script and openssh but is installed, by default, before them. It does not have dependencies by default, so, having the source, I rectified that by adding:
Requires: pam-script
Requires: openssh
to pam-config.spec. (I also tried Prereq: with same results.) As expected, with this change, it switches the ordering for pam-script and that error goes away. But it steadfastly refuses to change the order of installation for openssh, which is installed two packages after pam-config. [Openssh is dependent on coreutils and shadow (pwdutil), both of which are already installed at this point. It's also dependent (PreReq) on a mysterious macro, %{fillup_prereq}.]
Everything else installs (and runs) just fine, but I would like to understand better how rpm works. I thought if I used Required: to specify openssh in pam-config, that openssh would invariably be installed before pam-config. It worked for pam-script.
rpm -qp --requires on the .rpm file shows openssh. I repeated the install with the -vv option instead of -v. I can see the Requires: for openssh listed just the same as pam-script (YES (added provide)). I see a pam-config-0.91xxx -> openssh-7.2p2xxx listed under SCC #8: 11 members (100 external dependencies). I see the install of pam-config, which has no dependency information and nothing remarkable except for the %post scriptlet command that generates the error (pam-config --service sshd --delete --listfile). What other kind of things should I be looking at to debug this? What are these SCCs? Am I missing something about Requires? Or is there something obscure I may have overlooked, like circular, indirect, or hidden dependencies (I've checked for that, but ruled it out)? I've looked at several RPM tutorials and done a number of web searches and come up empty.
UPDATE: It appears that unlike pam-script, openssh is caught up in a mutual-dependency critical section. Here is the order of the packages actually being installed:
ruby2.1-rubygem-ruby-dbus-0.9.3-4.3.x86_64.rpm
pam-script-1.1.6-1.os42.gb01.x86_64.rpm
suse-module-tools-12.4-3.2.x86_64.rpm
kmod-17-6.2.x86_64.rpm
kmod-compat-17-6.2.x86_64.rpm
libcurl4-7.37.0-15.1.x86_64.rpm
pam-config-0.91-1.2.os42.gb01.x86_64.rpm
systemd-sysvinit-228-15.1.x86_64.rpm
krb5-1.12.5-5.13.x86_64.rpm
openssh-7.2p2-6.1.SBC.os42.gb01.x86_64.rpm
dracut-044-12.1.x86_64.rpm
systemd-228-15.1.x86_64.rpm
If I stage an installation on a production system and stop just before pam-config, it complains about being dependent on krb5, which is in the future! If I stop at ruby, it works. If I stop at pam-script, it works. If I stop at suse-module-tools, it complains about dependencies on dracut. So I'm wondering if RPM abandons its ordering principle within a mutual-dependency critical section, or if there is a dependency I haven't uncovered yet. I am using rpm -q --requires and rpm -q --provides to work this out. Stay tuned.
You can add more explicit sub-fields to the Requires tag, e.g. Requires(post): openssh-server or Requires(pre,post): openssh-server.
A single RPM transaction isn't really atomic, but is treated that way. Without this additional information, it just ensures that the packages are installed by the end of this transaction, which is "good enough" most of the time.
Another option is to put the required configuration into a %triggerin stanza, which I believe only executes once both packages are installed.

find whether a library is installed using shell script

I'm complete noobs in shell script what i want is shell script that determine a list of library/package currently installed if not install them without user permission
What I want is to determine the library/package is currently installed or not in system
I'm aware of aptitude search command but I looking for a better solution
e.g I have define(in shell script) check for readline library/package now how can I from inside the shell script (I want to create) know that readline package is currently installed or not.
Any idea or suggestion would certainly help
What I want is to determine the library/package is currently installed or not in system
dpkg -s does not require root permission, and will display package status details.
Example shell script:
#!/bin/sh
for P; do
dpkg -s "$P" >/dev/null 2>&1 && {
echo "$P is installed."
} || {
echo "$P is not installed."
}
done
Usage is:
script.sh package1 package2 .... packageN
For simply doing the test, it would seem that you could grep the output of a command such as ldconfig -p for your library of interest.
Or you could supply a tiny test program linked against the desired library, try running it, and test for non-failure.
If you are trying to set up a dependency check, the proper solution is to create a dummy package which Depends: on the packages you need to have installed. There is a tool called equivs which somewhat helps with this. (However, it has been criticized as being "over-engineered"; certainly, if you are familiar with the format of Debian packages, you might not need a separate tool if your requirements are this simple.) Then you just install this package and it will pull in the packages which are specified as dependencies.
You still have to know that the library which provides libreadline.so is libreadline5-dev. Debian package search can help find the package names you need to put in Depends:
You can probably do what you want with dpkg

How do YOU manage Perl modules when using a package manager?

A recent question here on SO got me thinking.
On most Linux distributions that I tried, some Perl modules would be available through the package manager. Others, of course, not. For quite a while I would use my package manager whenever I needed to install some CPAN module to find out whether a package was available or not and to install it when it was.
The obvious advantage is that you get your modules updated whenever a new version of the package becomes available.
However, you get in trouble when the module is not available in pre-packaged form and there are dependencies for that module that are. Firing up your package manager every time the cpan shell asks whether it should follow a dependency can be quite tiring.
Often, another drawback is the version of the pre-packaged module. If you are running Debian or Ubuntu you will soon find out that you will not be able to live on the bleeding edge, like many CPAN module authors seem to do.
How do other Perl people on Linux handle that problem? Do you just ignore what your package managers have to offer? Are there any tools that make apt (for example) and cpan better team mates? Or do you simply not install anything via the cpan shell?
For development, I install my own Perl and leave the system Perl alone. If I want to upgrade the system Perl, I use the system package manager. For my development Perl, I use the cpan tool.
Since I keep those separate, I should never mess up the Perl that the system needs for its maintenance tasks and so on, but I don't have to rely on the system's decisions for development.
It's very easy to install separate Perls. When you run Configure from the source distribution, it will ask you where you want to install everything. Give it any path that you like. I have many Perls installed in /usr/local/perls, for instance, and everything for each installation lives separately. I then make symlinks in /usr/local/bin for them (e.g. perl5.8.9, perl.5.10.0, perl5.10.0-threaded). When I want a particular version, I just use the one I want:
$ perl5.10.0 program.pl
The particular binary ensures that the program picks up the right module search path and so on (it's the same stuff in the Config.pm module for that binary).
Here's a script I use to create the symlinks. It looks in the bin directory, figures out the Perl version, and makes links like cpan5.10.1 and so on. Each program already knows the right perl to call:
#!perl
use 5.010;
use strict;
use warnings;
use File::Basename;
use File::Spec::Functions;
my $perls_directory = catfile(
$ARGV[0] // '/usr/local/perls',
'perl*'
);
die "$perls_directory does not exist!\n"
unless -d dirname $perls_directory;
my $links_directory = $ARGV[1] // catfile( $ENV{HOME}, 'bin' ); #/
die "$links_directory does not exist!\n" unless -d $links_directory;
foreach my $directory ( glob( $perls_directory ) )
{
say "Processing $directory...";
unless( -e catfile( $directory, 'bin' ) )
{
say "\tNo bin/ directory. Skipping!";
next;
}
my #perls = glob( catfile( $directory, qw( bin perl5* ) ) );
my( $perl_version ) = $perls[0] =~ m/(5\.\d+\.\d+)\z/;
say "\tperl version is $perl_version";
foreach my $bin ( glob( catfile( $directory, 'bin', '*' ) ) )
{
say "\tFound $bin";
my $basename = basename( $bin );
my $link_basename = do {
if( $basename =~ m/5\.\d+\.\d+\z/) { $basename }
else { "$basename$perl_version" }
};
my $link = catfile( $links_directory, $link_basename );
next if -e $link;
say "\t\tlinking $bin => $link";
symlink $bin => $link or
warn "\t\tCould not create symlink [$!]: $bin => $link!";
}
}
Everything gets install in the right place for that particular Perl.
I've also been thinking that I should put those Perl directories under some sort of source control. If I add a module I don't like, I just back out to an earlier revision. I'm only starting to do that though and haven't played with it much.
I've written more about this sort of thing in the Effective Perler blog:
Make links to per-version tools.
Manage your Perl modules with Git.
We install everything via the CPAN shell. This does ignore what package managers have to offer, but it avoids the headaches you mention when trying to work with them (firing for dependencies, using correct versions).
In addition, it means that our packages can be built programatically (or manually via the shell) on any platform where CPAN runs. Having a dependency on a package manager would affect your ability to distribute your software to platforms that don't use/support that package manager.
Since this question was originally asked, perlbrew has been released. It makes installing custom, self-contained perl installs trivial. And switching between those versions is just as easy:
perlbrew switch $version
I am using Debian for development, and production, and rely on debian Perl packages that are provided with the distro.
For cases where I need a Perl module that is not available in debian, I usually create my own debian package of it and install it.
Ofcourse, this method is not without faults, as a a lot of debian perl modules are outdated (at least in the current debian stable version - etch), and backporting something like Catalyst which has lots of dependencies is not practical.
However, by relying on the OS package manager, I retain all the great features of it, which bring easy maintenance, especially for deployed servers, as you know exactly what packages are installed, and a simple apt-get update;apt-get upgrade (from debian, or from a local repository) upgrades all servers to the same state, including the Perl modules.
I do the following on all my boxes:
I compile my own perl: I still use 5.8.[89] mostly, the stock 5.10.0 has a performance regression that hits me a lot, waiting for 5.10.1 to try again;
I use (and strongly recommend) the local::lib module to keep a module directory per project. Right now, that directory is rsync'ed to all the servers where the project is installed, but I'm testing using git instead;
I create a Task:: module for each project, so that I can install all dependencies with a single command.
I also use the cpan shell and local::lib.
You shouldn't need a Task:: for each project. Just use Module::Install (I like to use Module::Starter like this:
$ module-starter --mi --module=Module::Name --author="Me" --email=me#cpan.org
and then just pop your dependencies in requires 'module::dependency'; in the Makefile.PL. Finally when it's install time, you just perl Makefile.PL (answer yes) then make installdeps
[edit 5 years on from when I gave this answer originally]
These days perlbrew and cpanm are the things to use. local::lib still has a use-case, but the combination of perlbrew and cpanm solve a superset of those cases. Use local::lib when you're not prepared to compile your own perl.
I recommend use only cpan. The modules includes in Linux distro is only to cover package dependency. When you are installing linux without internet access with only CDs, it can't use cpan, so some modules are included as packages, but to a Perl developer this is bad.
Also I used to have a cpan configured to install modules in my home, (.perl) without root login needed.
For production:
In development, choose a version of the perl module which seems right for the requirements; if possible choose the target OS's shipped version (this makes most of the following superfluous), otherwise, pick another one. Create a RPM spec file for it. Use the clean build VM to build the RPM in a reproducable way (from a specfile / source checked in on the appropriate branch).
When the final build can be built (after merge), do the same build from the release branch, commit generated RPMs into deployment repository. This will be used in final validation and then released to production by being copied to the production repository.
All servers in production use the exact same binary that has been fully tested; they use the same spec file and source as the developer intended.
Perl modules are NOT upgraded by any process which does not follow this model. Nor is any other production software.
I use FreeBSD ports and wrap up all the CPAN dependencies in a "meta port" as a sort of a local port. FreeBSD has quite a large number of CPAN modules and their build system is approachable enough that you can easily write your own port if it doesn't exist--just dont forget to submit said port so it gets included in the ports tree. If the port doesn't have the current version in stock, you can always edit the Makefile for the port so it uses the new version, again don't forget to submit the change :-).
Lastly, I use Tinderbox to build the whole mess as binary packages that I then install on the all the production and development machines.
Bottom line--Once you get over your phobia of editing Makefiles, FreeBSD's ports are a great way to maintain your perl application and its dependencies.
I have started using Gentoo recently and Gentoo has a few very important advantages in this area. The first is that g-cpan is capable usually of installing many (though not all) modules from CPAN as Gentoo packages natively, though updating becomes a bit of a problem.
Usually on Gentoo, my approach is to use g-cpan to create an ebuild file, then install from that, tweaking if necessary. The advantage is that upgrading becomes really easy. I then move the file from g-cpan/perl to dev-perl and put it in an overlay for others to use. This allows me to quickly handle the cases g-cpan does not and gentoo packaging is a breeze anyway/

Resources