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

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.

Replies are listed 'Best First'.
Re^4: Meaning of XS object version
by eyepopslikeamosquito (Archbishop) on Jul 19, 2023 at 02:02 UTC

    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 think the question you should be asking is:

        How do I manage my non-OS perl installation (via perlbrew for example) with as little manual intervention as possible, as if I was updating it via my package manager?

        Edit:

        Sorry I missed this:

        After all our monthly patch cycles would pick up security items withou +t us having to monitor and manage these on our own.

        CPAN may not be the best for security reviews of modules.

        bw, bliako

        > As a development team we managed our own Perl on AIX/Unix. Upon our move to Red Hat GNU/Linux...

        Can you give us more background about your development team? Knowing that helps us provide more appropriate advice.

        • Is this a team of system administrators or software developers or both?
        • What programming language/s and tools does your team use?
        • Is it an inhouse development team ... or does it provide services to external clients?
        • Any Perl programmers in the team? :)

Re^4: Meaning of XS object version
by regalbraith (Novice) on Jul 19, 2023 at 20:15 UTC
    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.