The rpm creates a directory called "vendor_perl" and installs there. Unfortuntely, @INC doesn't know about this directory and so the module is not seen by perl. The simplest workaround is to install the source RPM and run rpm to install the source, and then manually make and install from the source directory to install in the correct location, which is /usr/lib/perl5/site_perl/5.6.1/i386-linux-thread-multi/ another workaround would presumably be to alter the default setting of the @INC variable to search in the vendor_perl directory. However, I am not a perl programmer and don't know how to do that.
You're trying to use a perl module from Rawhide with a perl that isn't from Rawhide. This isn't going to work very well, though the reverse should work (perl from rawhide, perl module not from rawhide). You should upgrade to the latest perl from Rawhide and use it. It sounds like you're recompiling perl to have threaded support; as a general point of reference, threaded perls and nonthreaded perls aren't compatible. The latest perl from rawhide knows about vendor_perl and uses it properly.
"You're trying to use a perl module from Rawhide with a perl that isn't from Rawhide." Are you sure about this? It just says it's from Redhat version perl-5.6.1-27. Is RedHat different from RawHide? Is 27 too old? "It sounds like you're recompiling perl" Nope, I'm just using your RPMs! Could this be a bug you don't know about? What's the rational for creating a RawHide only distribution-specific entity like "vendor_perl" in the first place?
Upgrading to 34.99.6 seems to have added the new "vendor_perl" directory and it also seems to have removed the threaded support, so whatever was wrong with my 27 rpm is not an issue any longer.
Ahh, you were just running a very old rawhide perl. There was a time it was threaded, but no longer. Sounds like everything is working correctly now?