in reply to Re: Meaning of XS object version
in thread Meaning of XS object version

On the broken host you have 2 versions of Template installed - an ancient one from the O/S package and a newer one from CPAN. On the working host you do not have the ancient one. Tentative solution: remove the O/S package from the broken host via yum (after backing everything up first, of course).


🦛

Replies are listed 'Best First'.
Re^3: Meaning of XS object version
by regalbraith (Novice) on Jul 18, 2023 at 17:40 UTC
    Thanks. That was my guess too. So I ran yum remove perl-Template-Toolkit. The XS object version issue no longer appears. Now I get to chase the next issue:
    Base class package "Template::Base" is empty.

      Though you seem determined to see this one through, I just want to strongly agree with cavac's response and add a further cautionary quote from Fletch:

      If you're doing anything serious with Perl you DO NOT want to use the OS' perl as that way lies much pain. Doing so couples you tightly to the OS' upgrade schedule for both the language and (if you're using its package manager for them) CPAN modules.

      Many of us have learnt the hard way not to meddle with the system Perl on Unix systems. Much less pain to roll your own that you can control and freely experiment with, without risking breaking the system Perl, and without the risk of OS upgrades to the system Perl breaking your production systems. The same basic arguments apply to Python and other scripting languages.

        Sadly I am coming to the same conclusion. As a development team we managed our own Perl on AIX/Unix. Upon our move to Red Hat GNU/Linux we looked forward to handing off that responsibility to the package manager (rpm via yum/dnf). After all our monthly patch cycles would pick up security items without us having to monitor and manage these on our own.

        If the struggle continues without resolution I'll cycle back to give that consideration. However, that would be non-trivial undertaking as I would not only need to install all the required modules but I also need to interface with the system installed httpd (Apache) that is hosting Bugzilla.

        I say "sadly" because I see see a lot of advantages in package management. But it only works if the OS vendor and sys-admin team avoid regressive steps.

      I was able to resolve the conflict by going back to the rpm 2.24 version after manually removing 3.101. Certainly not ideal! However, I am constrained by the work environment where these hosts live. Here are the steps to resolve. Please note: Moving packages backwards is not ideal. I'm being forced due to compatibility issues between rpm installed Perl and the needs of Bugzilla.
      cd /usr/local/lib64/perl5 tar cvf /var/tmp/perl5_Template.tar Template mv Template.pm Template.pm.3.101.notused yum install perl-Template-Toolkit

      Update 7/20: While I show tar being used for backup, my copy-paste here neglected to show the removal of the Template directory. Sorry about that.