Re: Conflict Between RPM and CPAN Shell Installation Method?

[Hrunting]

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).

[tye]

This is reportedly fixed in the latest CPAN.pm.

        - tye (but my friends call me "Tye")

[tilly]

This has actually been fixed since last spring.

There have been several versions of CPAN since then.