http://qs321.pair.com?node_id=910025

Hello monks!

Short Version!

I've written instructions in the form of a bash script that might actually work. Don't run it. Read it and use it as instructions.

wget http://search.cpan.org/CPAN/authors/id/G/GB/GBARR/Scalar-List-Uti +ls-1.23.tar.gz tar -xzf Scalar-List-Utils-1.23.tar.gz cd Scalar-List-Utils-1.23 perl Makefile.PL make make test || exit sudo make install INSTALLDIRS=site cpan <<END o conf make_install_arg INSTALLDIRS=site o conf mbuild_install_arg --installdirs=site o conf commit END

Long Version

I've had this reoccurring problem that I've finally figured out and I'm writing this meditation to document it. I specifically crafted the awkward title to make this findable by anyone in the same boat.

If you're on a redhat-based distro, such as Fedora or RHEL or CentOS, you may have met this problem. Basically, you start seeing "(something) is only available in XS version" and tons of stuff stops working, including CPAN.

The short term fix is to replace Scalar::Util. You can't use CPAN because CPAN depends on Compress::Zlib which uses Scalar::Util's dualvar.

The real problem is, the perl provided by redhat is busted in this particular way, always has been, and seems like it always be. Every time the perl RPM (redhat package) gets updated, it overwrites your lovely functional Scalar::Util with it's busted one, which is why it breaks from time to time without warning, particularly if you do automatic yum updates.

The obvious solution is to chuck out all the redhat perl stuff and replace it with perl from source. The problem with this is that anything packaged in an RPM will squawk at you if it depends on perl. It's too dumb to figure out that the requirements are met outside of the RPM.

Another possible solution would be to find a yum repository that offered non-busted perl rpms for your linux distro.

I took the lazy way and configured my system to install CPAN modules in a different place than redhat perl rpms. This means perl scripts will use my cpan installed modules while leaving the RPMS unchanged. The RPM system can be happy and my scripts can work. Joy!

Perl in redhat-based os's has a module search path that looks like this:

/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.8/i386-linux-thread-multi /usr/lib/perl5/5.8.8

The RPMs all install stuff under /usr/lib/perl5/5.8.8 and /usr/lib/perl5/5.8.8/i386-linux-thread-multi. I wanted to install my modules in /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi and /usr/lib/perl5/site_perl/5.8.8.

Both ExtUtils::MakeMaker and Module::Build have the mechanism to do this. To use it, add the appropriate arguments to the installer like so:

make install INSTALLDIRS=site ./Build install --installdirs=site

And make sure you configure cpan to do so as well. That can be done like so:

o conf make_install_arg INSTALLDIRS=site o conf mbuild_install_arg --installdirs=site o conf commit

Please note that the above assumes you didn't have anything else already in make_install_arg or mbuild_install_arg.

Now all my cpan modules go into the 'site' directories and the RPM modules go in the perl base directories. Any time perl needs a module provided by both, it will pick the CPAN one first.

...and if you wanted to know, the other valid settings for INSTALLDIRS are 'perl' and 'vendor'. You can read about it in ExtUtils::MakeMaker and Module::Build.