This was sort of the problem…basically I installed many Perl
modules via
cpanm and apparently that’s a problem in certain circumstances which
I’m not
totally sure about at this time. To fix this error I installed the
CentOS
@epel repo version of a few packages:
perl-UNIVERSAL-require.noarch…0.13-12.el7…@epel
perl-Log-Dispatch.noarch… 2.41-1.el7.1…@epel
These are from @epel (as shown above) but now I’m stuck with an error
based
on a perl module that does not have a package published in the epel
repo:
Can’t locate /Symbol/Global/Name.pm/ in @INC (@INC contains:
/root/perl5/lib/perl5/ /opt/rt4/sbin/…/local/lib /opt/rt4/sbin/…/lib
/usr/local/lib64/perl5 /usr/local/share/perl5
/usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at
/opt/rt4/sbin/…/lib/RT/Config.pm line 57.
BEGIN failed–compilation aborted at /opt/rt4/sbin/…/lib/RT/Config.pm
line
57.
Compilation failed in require at /opt/rt4/sbin/…/lib/RT.pm line 159.
After getting this I searched the repo’s for this package, I found and
installed this one:
perl-Symbol-Util.noarch 0.0203-4.el7 @epel
But this did nothing for me and doesn’t seem to be what RT/Perl/httpd
wants…
Right. If there was a package for the EL7 distro family that gave you
just the Symbol::Global::Name module, its base name would be
perl-Symbol-Global-Name, and if that module were part of a larger
package it would probably be perl-Symbol-Global or perl-Symbol.
BUT: the way to find a specific-file dependency with yum is the
‘provides’ command:
[root@requesttracker ~]# yum provides */Symbol/Global/Name.pm
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
* base: mirrors.tripadvisor.com
* epel: mirror.cogentco.com
* extras: centos.firehosted.com
* remi: remi.check-update.co.uk
* remi-safe: remi.check-update.co.uk
* updates: bay.uchicago.edu
No matches found
Oh well… that is why I used CPAN on that machine (via ‘make fixdeps’)
to install Symbol::Global::Name.
So…It looks like I will have to build a package for the module
“Symbol::Global::Name” that I can install with yum…I tried the
hacked
up solution suggested in the blog post you referenced, the OP said in
the
quote below that this fixed it for him but I had no luck, it’s a
hacked in
solution anyhow…
“I fixed the issue by adding the following line in ther perl script
before
any ‘use’ command.”
use lib “/root/perl5/lib/perl5/” ;
Smart choice. That’s not maintainable for RT. Also: won’t work unless
you disable or reconfigure SELinux and open up /root/perl5/ to the
apache user, which would be generally unwise things to do.
Looks like your suggestion of installing a separate instance of perl
that’s
dedicated to RT is making more and more sense the deep down the rabbit
hole
that I travel…I’m afraid that if I install a new separate instance
of
perl it will break even more things since I suppose I probably have to
recompile RT after doing so and I don’t want to lose the configuration
state
of RT/RT-IR…
I just saw Bill Cole’s reply and it is EXCELLENT!!! I’m still
re-reading to
comprehend but Bill if you get this reply I was drafting prior to
seeing
your response so if you need to update your great info based on what
I’ve
said here I’d be very grateful!!
Well, in looking at it again I think maybe I should have also noted that
those PERL* variables set in either .bashrc or .bash_profile will stay
with any shell launched with them set and its offspring, so you will
want to log out and back in after fixing the files or:
unset PERL_LOCAL_LIB_ROOT PERL_MB_OPT PERL_MM_OPT PERL5LIB
BEFORE trying to install anything with CPAN or RT’s make fixdeps.
And a bit of background: if you install a Perl module using yum from the
Base or EPEL repos, it may install pieces under any of the 6 roots shown
by ‘perl -V’ depending on the mood of some junior RedHat intern on a
random Tuesday in 1997. Mostly they SHOULD stay out of the /usr/local
ones and only get 64-bit-specific things in the lib64 ones. There’s also
supposedly “logic” determining what does and doesn’t go in vendor_perl
but it’s not obvious. If you install using CPAN in a pristine (no PERL*
variables) environment, you should get a bit better determinism, since
the vendor_perl roots should be avoided entirely and /usr/local/* should
be the only place anything lands. However, if you let CPAN upgrade
modules already installed as part of the canonical Perl base (i.e. not
“local” or “vendor_perl”) it might clobber files that the RPM/yum
subsystem believes belong to particular packages and expect have
particular checksums. Hilarity (or something akin to it…) shall ensue
when you try to upgrade those with yum. On the other hand, it SHOULD
just install under /usr/local and override the system version at
runtime. I don’t suggest relying on that.
SO: you don’t actually need to build a special Perl for RT. but the
alternative is to be careful about how you install Perl modules. Check
yum first for dependencies, and install from the Base or EPEL repos if
they have what you need in the correct version. If you need a module not
in those repos, use CPAN. If you need a different version that what yum
has already installed, remove it first before installing from CPAN. Note
that RT’s ‘make fixdeps’ always installs from CPAN. Note that you could
also ONLY use CPAN to maintain a unified Perl world, but that is a
hassle: worse than either a blended yum+CPAN world or 2 distinct worlds.
somewhere in the pathes below: