Re: How to fix Perl Installation after system upgrade

This likely stems from having Perl modules with a compiled component ("XS") from the old Perl version, but a new (system) Perl version now.

The solution is to reinstall all the Perl modules that you installed previously.

A second solution would be to install a Perl version identical to the old system Perl, but it is relatively hard to replicate the exact compiler settings etc. used for the old system Perl.

In the long run, there are two approaches:

Maintaining a list of prerequisite modules for your programs, and reinstalling that on every upgrade
Maintain a separate Perl installation and be independent from system upgrades

Both have upsides and downsides - with the first option, you get automatic upgrades, with the second, you don't get them.

Comment on Re: How to fix Perl Installation after system upgrade

Replies are listed 'Best First'.
Re^2: How to fix Perl Installation after system upgrade by monsignor (Acolyte) on Nov 03, 2022 at 20:29 UTC
@Corion Thanks very much for the reply. Now what is the easiest way to fix this? Can anyone see a problem with simply taking this list of all the installed perl modules and running *apt reinstall list-of-modules* You mentioned "XS" -- does that have any connection to xs in the module names (in my list)? Would just reinstalling those fix the issue? What about perlbrew? I have perlbrew installed. Do perlbrew config files contain any important data that needs to be preserved? (Other than a list of installed modules?) How can I compile a list of any modules that are installed in perlbrew? It seems to me that this should be a mechanical process to recreate a fresh installation, or am I missing something? Thanks again for the assist!	[reply]
Re^3: How to fix Perl Installation after system upgrade by Fletch (Bishop) on Nov 04, 2022 at 05:56 UTC
The “autobundle” command for CPAN will help with what’s installed but if you installed with the package manager that’s probably as good a place to start; however it’s possible you’ve possibly gotten your Perl install into a state it (CPAN) may not run. This kind of wonkiness is why if you’re doing anything serious with perl it’s going to be much more controlled (by which I mean under your control) to make a separate install from the OS’ (using perlbrew or from source) and only install after-market modules into that copy (and/or a local::lib dir) using CPAN (or cpanp or cpanm) rather than being subject to the package manager’s whims. The cake is a lie. The cake is a lie. The cake is a lie.	[reply]