Anyone familiar with packaging modules as RPMs for in-house use?
At work we have someone that's been working on turning our in-house modules
into RPMs, a process I'm not very familiar with.
Yesterday he had a bug where it turned out we had a modified version of a
CPAN module in one of our RPMs, but it got installed lower in @INC so the
unmodified CPAN version also installed on the machine was getting loaded.
His solution was to modify PERL5LIB in the environment to make @INC point to
our version first. What I'm wondering is if we should instead look at the
way our in-house modules get built and turned into RPMs to make them
preferred in @INC.
(Frankly, the better solution is to rename the module -- although in this
case we were modifying a module that is used by another CPAN module, so we
would have to modify that to use the different name, also.)
Our in-house module got installed (via RPM)
in: /usr/local/lib/perl5/site_perl/5.10.0
And the CPAN version in: /usr/lib64/perl5
Is this expected, or if not what approach should we use to get our modules
to be preferred?
@INC:
/usr/local/lib64/perl5
/usr/local/share/perl5
/usr/lib64/perl5
/usr/share/perl5
/usr/lib64/perl5
/usr/share/perl5
/usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi
/usr/local/lib/perl5/site_perl/5.10.0
/usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.10.0
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/site_perl/5.10.0
/usr/lib/perl5/site_perl
.
--
Bill Moseley
mose...@hank.org
