Conflict Between RPM and CPAN Shell Installation Method?

dave_aiello has asked for the wisdom of the Perl Monks concerning the following question:

I am attempting to install the new version of the Slash content management system (aka Bender) on a machine running Version 6.2.3 of VA Linux's distribution. This distribution is essentially Red Hat 6.2, and includes Perl 5.00503 installed as an RPM. The Slash installation instuctions tell me to invoke the CPAN shell:

$ perl -MCPAN -e shell

Then, to install Bundle::Slash:

cpan> install Bundle::Slash

The problem I ran into was that something in Bundle::Slash, when combined with my settings for CPAN.pm (like prerequisites_policy "follow"?), result in one of the modules in Bundle::Slash triggering the installation of Perl 5.6.0 via CPAN. This occurs in the midst of the installation of Bundle::Slash.

The installation of Perl 5.6 has a number of side effects. Chief among them is an error in the installation of DBI and DBD::mysql. Repeated attempts to install these modules from the CPAN shell fail. One way around the DBI and DBD::mysql problems is probably to install these modules manually. This is what I intend to try later. (Let me know if you think I am off base with this.)

My main question is how to deal with the aftermath of the Perl 5.6 installation? Perl 5.6 appears to be installed:

$ perl -v
This is perl, v5.6.0 built for i686-linux
Copyright 1987-2000, Larry Wall

...but rpm thinks that the rpm called perl-5.00503-10 is installed:

$ rpm -q perl
perl-5.00503-10

Shouldn't I be attempting to make the RPM installed agree with the Perl version that is currently being executed? If so, what parts of the configuration do I need to change?

If I simply uninstall the currently installed Perl RPM, I will need to use some technique to force it because of the number of packages that depend upon it in the RPM database.

I do not need the RPM system to manage the tools I use to install, operate, and modify Slash. But, I would like to continue to use RPM to install software that I run as a casual user. If I simply remove the Perl RPM, it seems likely that the package manager will be far less useful, in that it will not have dependencies that reflect reality anymore.

I would be happy to provide more information, if that would help.

Dave Aiello
Chatham Township Data Corporation

Comment on Conflict Between RPM and CPAN Shell Installation Method?

Replies are listed 'Best First'.
Re: Conflict Between RPM and CPAN Shell Installation Method? by Hrunting (Pilgrim) on Feb 08, 2001 at 01:23 UTC
Yes, if you have your policy set to follow and your package requires a core module with a version newer than your current system, then the new version of perl will be downloaded and compiled for you. I doubt that anything in the Slash code actually requires 5.6.0, but you never know. This is one of the worst parts of using CPAN, and one of the reason I don't use it anymore. Well, by default, the perl RPM installs into /usr on RedHat systems, while perl's build process installs into /usr/local by default. I recently reinstalled RH7 from CD, and I wanted to compile my own version of perl for some other software I was using. I uninstalled the Perl RPM using --nodeps, then compiled my own. If you flip them around, then your /usr/bin/perl gets erased (although technically, you should just be able to copy /usr/local/bin/perl to /usr/bin/perl or symlink them). If you do that, of course, you simply have to install packages that required perl with --nodeps. There might be a way to add an entry to the RPM database without actually installing that file, but I don't know what it is. what I do is try to install the package normally first and if it fails because of a perl dependency, I install it with --nodeps. That way I can still catch dependency failures. BTW, if you upgrade to RH7, make sure that you compile perl with kgcc and not gcc. Perl's installer has problems with the gcc libs provided by RH7, and they can cause socket problems (among other things, I discovered).	[reply]
(tye)Re: Conflict Between RPM and CPAN Shell Installation Method? by tye (Sage) on Feb 08, 2001 at 01:36 UTC
This is reportedly fixed in the latest CPAN.pm. - tye (but my friends call me "Tye")	[reply]
Re (tilly) 2: Conflict Between RPM and CPAN Shell Installation Method? by tilly (Archbishop) on Feb 08, 2001 at 04:00 UTC
This has actually been fixed since last spring. There have been several versions of CPAN since then.	[reply]
Re: Conflict Between RPM and CPAN Shell Installation Method? by Jerry A! (Acolyte) on Feb 08, 2001 at 03:13 UTC
RPM installs perl into /usr. Autobuilding perl via CPAN installs perl into /usr/local. Do a perl -v on /usr/bin/perl and /usr/local/bin/perl and you should see the differences. Okay, no biggee, but not expected behavior either. So you have to specify /usr/bin/perl or /usr/local/bin/perl. Of course there's the issue of making sure that your have the correct modules in each perl installation. Ugh... This looks like a place for CPAN.pm. Run perl as /usr/bin/perl -MCPAN -e 'autobundle' and create a bundle of your locally installed perl packages. The run /usr/local/bin/perl -MCPAN -e 'install Bundle::autobundle_name'. That should then install all the correct modules under the /usr/local install. Keeping the two in sync is an exercise I'll leave up to you. I would probably recommend doing an rpm -e, and strictly using the /usr/local version of perl. But I'm evil that way... --Jerry	[reply]
Re: Conflict Between RPM and CPAN Shell Installation Method? by arturo (Vicar) on Feb 08, 2001 at 05:05 UTC
If you want to keep the old (from RPM) Perl around, it probably won't do you any harm to do so, and you'll get all that lovely package management too. The only thing you'll have to look out for are potential nasties from having different perl executables around, but those aren't usually terrible (i.e. you may be puzzled why the script acts differently when run as `perl foo.pl` and `./foo.pl`). I like keeping my RPM database consistent and up to date on my desktop systems, because I think things are just easier that way. On a server, you might want a more DIY approach. You could (assuming this wouldn't break your Slash install, and I see no reason that it should) nab a perl 5.6 rpm , or nab the source RPM and build it yerself (`rpm --rebuild` rocks) Philosophy can be made out of anything. Or less -- Jerry A. Fodor	[reply] [d/l] [select]


Keep It Simple, Stupid
	PerlMonks