Red Hat Bugzilla – Bug 62923
Date::Calc perl module is installed in a bogus location
Last modified: 2008-05-01 11:38:01 EDT
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,
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?