[tpm] [Fwd: Perl and putative DLL Hell]

[Brian Mielke]

I fully agree with what Stuart said.

Until a few years ago I didn't realize anyone used system perl for
production worthy code.  My last two jobs have used it though, and I have
since found out it's pretty common.  I'd avoid it like the plague so you
can control what's in your perl without affecting your system and vice
versa.  Perlbrew simplifies some of this.  If you're relying on system perl
you'll be hindered if you want to use newer perl versions and features.
There are a lot of good things post 5.20, but centos is still running a
really old copy of perl afiak.

If you're having issues upgrading your OS because your use of system perl,
now seems like the perfect time to decouple and build your own perl
version, use that, and stop using system perl.  I know this may not be
realistic depending on how big of a code base / monolith you're looking at,
but it may be best to pull off the bandaid and slug through this work.

- Brian

On Thu, Mar 12, 2020 at 12:21 PM Stuart Watt <stuart.watt at turalt.com> wrote:

> TL;DR: don't use a system perl if you can possibly help it.
>
> My suggestion is: it is never a good idea to use a "system" perl for your
> application. The distribution is highly likely to patch it in odd or
> unusual ways, and at times you don't want them to. This strategy grew out
> of having to deploy on CentOS, but other distributions have the same
> challenge, they just aren't quite as terrible. I had misery with a
> CentOS-hacked variant of some DBD driver, for example, causing real angst,
> which was completely at odds with CPAN, and both arrived and left with OS
> updates.
>
> I've tended to use perlbrew to get a specific version, and point my
> application/scripts to that, even in production. That has the additional
> advantage it can belong to a non-root user which makes maintenance very
> much safer. This strategy doesn't play as nicely with, e.g., mod_perl,
> but anything that's FastCGI-based works fine. And mod_perl is a can of
> worms anyway. Regular scripts also work fine, especially if you are
> careful with using, e.g., Probe::Perl to find the *current* binary and had
> that on if you are running other scripts so that the shebang doesn't get
> you. Or point the shebang to your own perl to get it disconnected from the
> system perl, or (better) use /usr/bin/env to find the perl in the shebang.
>
> All the best
> Stuart
>
> On Thu, Feb 6, 2020 at 3:15 PM <arocker at vex.net> wrote:
>
>>
>> I can'thelp with this, being seriously out of contact for another month.
>> Can anyone offer help/advice/suggestions?
>>
>> ---------------------------- Original Message ----------------------------
>> Subject: Perl and putative DLL Hell
>> From:    "Dave Collier-Brown" <Dave.Collier-Brown at indexexchange.com>
>> Date:    Thu, February 6, 2020 10:05 am
>> To:      "Alan Rocker" <arocker at vex.net>
>> --------------------------------------------------------------------------
>>
>> We have an "interesting" problem with perl on Centos 7 and 8. One of my
>> colleagues, Jourdain Casale  wrote:
>>
>> Okay well if 7 is easier we are doing it first and Perl / CPAN / Linux
>> dependencies are really bad migrating to 8
>> 6 is ancient a lot of CPAN won’t build in 8
>> Modules work great but only on the Linux they were built for
>> A lot of refactoring and risk in 8 vs 7
>>
>> Jourdain Casale  9:47 AM
>> It’s dependency hell
>> Like the Linux Perl equivalents of DLL Hell in windows
>>
>> We're running Centos 6, and I'd like us to go forward to 8 (8.1, actually)
>> but the teams who tried out updating the perl found it really hard on 8,
>> and hard enough on 7 that they put it off again and again.
>>
>> If it's really as hard as they thought, I figure you've heard the
>> community talking a lot about it.  I do see some blathering via a google
>> search, but nothing as severe as was being reported to Jourdain.
>>
>> Can you help?
>>
>> --dave
>> _______________________________________________
>> toronto-pm mailing list
>> toronto-pm at pm.org
>> https://mail.pm.org/mailman/listinfo/toronto-pm
>>
>
>
> --
>
> Stuart Watt
>
> Chief Technology Officer
>
> t: +1 416-522-8287 | e: stuart.watt at turalt.com | w: turalt.com
> _______________________________________________
> toronto-pm mailing list
> toronto-pm at pm.org
> https://mail.pm.org/mailman/listinfo/toronto-pm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.pm.org/pipermail/toronto-pm/attachments/20200312/ba83bc1c/attachment-0001.html>