That's true, it's risky. I've not seen rpm remove a needed module as part of an upgrade, but even if it did, it's so easy to refill the hole using CPAN.
I was mis-remembering the common failure case, which you point out in a subsequent message, the case where the distro upgrade down-revs a package.
I have to use systems where RPMs must be supplemented from CPAN because (as noted elsewhere) I must install the Perl RPM to support other system utilities, and RPMs (especially current ones) are not available for many modules.
Are you aware of RPM::Specfile? It includes the cpanflute2 script for rebuilding a CPAN module into an RPM. I've rarely found CPAN modules that require special tweaking. I think the one I had a problem with was due to the version numbering causing grief with the tarball name not matching the RPM name.
The more fundamental problem is that multiple packaging systems keep independent databases recording what's installed on the system. What's needed is a way for CPAN to use the native package database to keep its state.
Yeah, and world peace, too. :-) Sorry. But that is a pretty tall order. First there's RPM. Then, I think Debian (or one of the other distros) has a different system. HP-UX has its own system. Anyone else want to toss in another clinker?
Hehe, yeah, I didn't think it would be *easy*. ;) But you could probably come up with a plugin-based system so that each environment could include its own module underneath to glue CPAN to the native DB.
