5.0.2 Upgrade GnuPG::Interface >= 1.02

Hello,
We are attempting to Prep out the upgrade from 5.0.1 to 5.0.2 on a CentOS 7 server, and are getting the following error when running the “make testdeps”

GnuPG::Interface >= 1.02 … MISSING (have 1.00)

The “make fixdeps” command as well as attempting to force an install from cpan doesn’t seem to resolve the issue:
cpan install -f GnuPG::Interface

Any ideas as to how to work around this?

The force install always works for me when I run into this issue on CentOS 7. Is it possible that 1.0.2 installed in a different location than your other Perl modules, and therefore cannot be found when the testdeps command is ran?

Can you specify the version of GnuPG::Interface you’re installing?

CPAN is trying to install: GnuPG-Interface-1.02.tar.gz

Is that failing? What version of gpg do you have gpg --version might be the command

gpg --version

gpg (GnuPG) 2.0.22
libgcrypt 1.5.3

Does CPAN is trying to install: GnuPG-Interface-1.02.tar.gz install successfully? Maybe try uninstalling 1.00 first?

It looks like Sean is correct, Perldoc shows that the package is installed in:
/usr/local/share/perl5/GnuPG/ which is version 1.0.0,
but it looks like cpan is installing the new package here:
/usr/local/share/perl5/lib64/perl5/GnuPG and testdeps isn’t finding it.

Is there a way to point to this location during configuration?

I’ve hit a similar problem—the inability to find GnuPG—and was able to use a symlink to resolve it. Plenty of caveats: I’m running a different OS, compiled perl and installed in /opt/perl, the machine is single purpose, etc., etc. But maybe that will get you close.

I ran into the exact same issue on our CentOS7 box. If you manually install the GnuPG 1.02 Interface using a force, then the rest of the upgrade goes off without a hitch

Odd that that didn’t work for us. We attempted the force, and it still didn’t work.

FWIW I use perlbrew for RT so I have good control over all the libraries being exactly what RT wants. That said, Perl’s library search path is controlled by the PERL5LIB variable; I wonder if in your example, RT’s Perl includes /usr/local/share/perl5 but not /usr/local/share/perl5/lib64/perl5/ ?