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

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.

Replies are listed 'Best First'.
Re^5: Meaning of XS object version
by regalbraith (Novice) on Jul 19, 2023 at 13:44 UTC

    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.

[reply]

      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.

      [download]

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

      bw, bliako

[reply]
[d/l]
[select]
[reply]
[d/l]
[select]

      > 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? :)

[reply]

In Section Seekers of Perl Wisdom