The paths in @INC do not look good. If the modules have been installed in /root/perl5/lib/perl5/ and you are not root then you won't be able to use them. They certainly should not have been installed in /usr/local/bin/perl - I cannot imagine why that might be in @INC in the first place. The other paths all relate to perl 5.32 which isn't the system perl in any RHEL release AFAIK (although there may be an SCL for it).

Since I'm not the one who installed perl onto this system, nor can I contact them, what is the best possible solution to resolve this issue?

Perhaps uninstall this perl 5.32 and just use the system perl? Either that or install your own perl via perlbrew and start that one from scratch. If someone has installed a non-system perl and done it badly then who knows what other problems they have left behind.

You need to find where the modules were installed so that you can supply those paths to lib pragma: use lib '/path/to/module';. Or, install the software on your own in known locations.

One way to find the file paths of system installed software ...

# Locate LWP::UserAgent.
% rpm -qa | fgrep -i useragent

# Take the name from above to find the installed paths.
% rpm -ql <package name> | fgrep LWP/UserAgent
[download]

Then use the paths from above command output to supply to lib pragma.

Below is an example for "DBD::SQLite" module installed here on CentOS 8 ...

% rpm -qa | egrep -i '(perl|p5).+SQLite'
perl-DBD-SQLite-1.58-2.module_el8.1.0+207+bdacd7b7.x86_64

% rpm -ql perl-DBD-SQLite-1.58-2.module_el8.1.0+207+bdacd7b7.x86_64 | 
+fgrep 'DBD/SQLite'
/usr/lib64/perl5/vendor_perl/DBD/SQLite
/usr/lib64/perl5/vendor_perl/DBD/SQLite.pm
/usr/lib64/perl5/vendor_perl/DBD/SQLite/Constants.pm
/usr/lib64/perl5/vendor_perl/DBD/SQLite/Cookbook.pod
/usr/lib64/perl5/vendor_perl/DBD/SQLite/Fulltext_search.pod
/usr/lib64/perl5/vendor_perl/DBD/SQLite/VirtualTable
/usr/lib64/perl5/vendor_perl/DBD/SQLite/VirtualTable.pm
/usr/lib64/perl5/vendor_perl/DBD/SQLite/VirtualTable/FileContent.pm
/usr/lib64/perl5/vendor_perl/DBD/SQLite/VirtualTable/PerlData.pm
/usr/lib64/perl5/vendor_perl/auto/DBD/SQLite
/usr/lib64/perl5/vendor_perl/auto/DBD/SQLite/SQLite.so


# In Perl program, if "/usr/lib64/perl5/vendor_perl" had not been
# already included in @INC which it is per "perl -V" (near the bottom)
+.
...
use lib q[/usr/lib64/perl5/vendor_perl];
...
[download]

Hello monks,

Thanks for your inputs. I took the easy way out and installed the tool on a conda environment, but I have noted the perl issues and suggestions. Once time permits I think I might just use the system perl.

If you're doing anything serious using the OS' perl is probably not what you want to do. If you're using the OS' perl then you're at the mercy of the sysadmin and/or whatever update schedule the upstream OS pick WRT when perl upgrades. Your best bet is to compile your own perl (perhaps using perlbrew) and explicitly use that instead. You'll have control of when you upgrade, what's installed from CPAN into that install (although you may want to be using local::lib as well).

It's more effort, but you'll appreciate the headache(s) you save yourself because you don't have to track down and fix things after your sysadmin (or RHEL) decides to force you to jump perl versions because a third order dependency makes /usr/bin/perl to jump versions and now all of your CPAN modules disappear.

(Caveat: if you're in a containerized environment and know you can lock down versions and what's installed specifically within your container and you're isolated from changes to the (base) underlying OS then this isn't as relevant a suggestion.)

Edit: While I'm not completely enamored with it as the mechanism your using anaconda I'd say is another acceptable solution akin to using perlbrew; the main thing is not tying yourself to the OS' perl. You want your application to run against a perl you completely control.

The cake is a lie.
The cake is a lie.
The cake is a lie.