3 modi per installare Perl su Ubuntu Server 24.04 e 22.04

Su Ubuntu Server 24.04 e 22.04 il punto non è solo “installare Perl”, ma scegliere quanto vuoi legarti al sistema operativo. Per un server standard basta il pacchetto del repository. Se devi compilare moduli XS o mantenere dipendenze native, serve anche la toolchain. Se invece vuoi isolare versioni e moduli per progetto, conviene affiancare un gestore di ambienti come perlbrew o una soluzione equivalente. I tre approcci risolvono problemi diversi e non si escludono a vicenda.

La differenza pratica tra 24.04 e 22.04 non è nel modo in cui installi Perl, ma nel fatto che il pacchetto di distribuzione cambia versione e quindi cambiano anche i moduli disponibili nei repository e la compatibilità con eventuali script legacy. In altre parole: prima decidi il requisito, poi scegli il canale di installazione. Installare “a caso” su un server di produzione porta quasi sempre a conflitti tra moduli di sistema, script applicativi e aggiornamenti futuri.

1) Installazione dal repository Ubuntu: la scelta predefinita

Se ti serve Perl per script di sistema, automazioni, tool di manutenzione o applicazioni che non richiedono una versione specifica, il pacchetto ufficiale è la strada giusta. È la via più pulita perché segue il ciclo di sicurezza di Ubuntu, si integra con gli aggiornamenti e non introduce binari fuori controllo nel sistema.

Su entrambe le release puoi verificare la versione disponibile prima di installare:

apt-cache policy perl

Su 24.04 troverai una versione più recente rispetto a 22.04. Se il tuo codice usa moduli o sintassi vecchi, questa differenza va trattata come un requisito tecnico, non come un dettaglio.

Installazione base:

sudo apt update
sudo apt install perl

Per controllare cosa è stato installato e dove si trova l’eseguibile:

perl -v
which perl
perl -e 'print $^V, "\n"'

Il risultato atteso è un interprete funzionante, visibile in /usr/bin/perl o nel path equivalente gestito da alternatives se hai più installazioni presenti. Su un server pulito, in genere, non serve toccare altro.

Se devi usare moduli CPAN comuni, spesso basta aggiungere quelli confezionati da Ubuntu:

apt search '^lib.*-perl$'

Questo approccio è il più robusto quando la priorità è la manutenzione: gli aggiornamenti di sicurezza arrivano tramite i normali canali APT e non devi inseguire compilazioni manuali per ogni host.

2) Installare anche la toolchain: quando i moduli vanno compilati

La seconda strada non sostituisce Perl: lo completa. È quella che ti serve quando installi moduli CPAN con componenti native, per esempio librerie che compilano codice C o che dipendono da header di sistema. Senza toolchain, l’installazione dei moduli fallisce in modo poco leggibile e finisci a inseguire messaggi tipo “missing Makefile.PL dependencies” o errori di compilazione.

Pacchetti tipici:

sudo apt update
sudo apt install build-essential perl-modules make gcc

In molti casi è utile aggiungere anche gli header e gli strumenti di base per CPAN:

sudo apt install libwww-perl curl ca-certificates

Se il pacchetto richiesto non è nei repository Ubuntu, puoi usare il client CPAN. La via più ordinata, oggi, è cpanm o il bootstrap del modulo CPAN, ma prima verifica che il sistema abbia i prerequisiti minimi. Un’installazione CPAN su un host senza compilatori è solo rumore operativo.

Esempio di installazione del gestore moduli:

sudo apt install cpanminus

Poi puoi installare un modulo nel contesto di sistema o, meglio, in un ambiente dedicato se non vuoi contaminare il Perl di distribuzione:

cpanm Mojolicious

Attenzione però: installare moduli globalmente su un server condiviso crea dipendenze difficili da rimuovere. Se lo fai, documenta sempre la lista dei moduli e conserva la motivazione del change. In produzione, la domanda giusta non è “si può fare?”, ma “chi lo manutiene tra sei mesi?”.

3) Versioni isolate per progetto: perlbrew e simili

La terza strada è quella giusta quando hai applicazioni legacy, script interni con dipendenze vecchie o progetti che richiedono una versione specifica di Perl diversa da quella del sistema. Qui l’obiettivo è separare il runtime applicativo dall’OS, così un aggiornamento di Ubuntu non ti rompe l’ambiente dell’app.

Con perlbrew puoi compilare e gestire più versioni di Perl sotto il tuo utente o sotto un account dedicato. È una scelta molto più controllabile rispetto a sovrascrivere il Perl di sistema o forzare symlink manuali.

Prerequisiti minimi:

sudo apt update
sudo apt install curl build-essential perl

Installazione di perlbrew:

curl -L https://install.perlbrew.pl | bash

Dopo l’installazione, abilita l’ambiente nella shell corrente:

source ~/perl5/perlbrew/etc/bashrc

Lista delle versioni disponibili e installazione di una release specifica:

perlbrew available
perlbrew install perl-5.38.2
perlbrew switch perl-5.38.2

Verifica immediata:

perl -v
which perl

Il vantaggio vero non è estetico: è operativo. Puoi avere un Perl di sistema lasciato intatto e uno o più Perl applicativi per ambienti diversi. Questo riduce i conflitti con pacchetti di Ubuntu e rende più semplice riprodurre un setup su macchine diverse.

Se il tuo flusso di lavoro richiede anche moduli isolati per versione, perlbrew si combina bene con cpanm e con un file di dipendenze per progetto. In quel caso il repository del sistema resta il livello base, mentre l’ambiente applicativo vive separato. È il compromesso più sano quando gestisci più applicazioni Perl sullo stesso host.

Quale metodo scegliere su 24.04 e 22.04

La scelta dipende dal tipo di server, non dalla moda del momento. Se il tuo obiettivo è amministrazione ordinaria e script locali, usa il pacchetto Ubuntu. Se devi compilare moduli, aggiungi la toolchain. Se gestisci applicazioni con requisiti di versione rigidi, isola il runtime con perlbrew o una strategia equivalente.

Una regola pratica utile:

• Server di sistema: apt install perl.
• Server con moduli CPAN nativi: Perl di sistema + build-essential + eventuali librerie di sviluppo.
• Applicazione legacy o multi-versione: Perl di sistema intatto + ambiente isolato per progetto.

Su Ubuntu 22.04 la probabilità di incontrare dipendenze che si aspettano versioni più vecchie è leggermente più alta, ma non è un motivo per evitare gli aggiornamenti. È un motivo per testare gli script prima del cambio di release e per non mischiare moduli installati a mano con quelli gestiti da APT senza una policy chiara.

Verifiche post-installazione che evitano sorprese

Dopo l’installazione conviene sempre fare quattro controlli. Sono rapidi e ti dicono subito se stai usando il Perl giusto o se hai già un conflitto di path.

1. Controlla il binario effettivo: which perl.
2. Controlla la versione: perl -v.
3. Controlla i moduli attivi: perl -MConfig -e 'print $Config{archname}, "\n"'.
4. Controlla che gli script usino l’interprete atteso leggendo lo shebang: head -n 1 /path/script.pl.

Se uno script punta a /usr/bin/env perl, allora dipende dal PATH. In un ambiente con perlbrew o con più runtime installati, questo dettaglio conta molto più della versione stampata da perl -v. È qui che nascono molti casi di “funziona in shell ma non da cron”.

Per i job pianificati, verifica sempre l’ambiente reale:

crontab -l
sudo grep -R "perl" /etc/cron* /var/spool/cron 2>/dev/null

Se il cron usa un PATH più corto della tua sessione interattiva, va esplicitato. È una delle cause più banali e più frequenti di errore nei server Unix-like.

Errore tipico: moduli mancanti dopo l’installazione

Uno scenario classico è questo: Perl è installato, ma uno script fallisce perché manca un modulo. Qui la diagnosi corretta non è reinstallare Perl. La diagnosi è capire se il modulo deve arrivare da APT, da CPAN o da un ambiente isolato.

Per vedere se il modulo è presente:

perl -MModule::Name -e 'print "ok\n"'

Se il comando fallisce, hai tre opzioni: cercare il pacchetto Ubuntu corrispondente, installare il modulo via CPAN nel contesto corretto, oppure spostare l’applicazione in un ambiente gestito separatamente. In produzione la seconda opzione è accettabile solo se hai una procedura di aggiornamento chiara e ripetibile.

Per cercare un pacchetto Debian/Ubuntu associato a un modulo Perl:

apt-cache search libmodule-name-perl

La mappatura non è sempre ovvia, ma quando esiste è preferibile al modulo installato a mano nel sistema globale. Riduce il rischio di drift tra ambienti e semplifica il rollback.

Scelta pratica finale

Se devi mettere in piedi un server Ubuntu 24.04 o 22.04 oggi, la sequenza sensata è questa: installa Perl dal repository, aggiungi la toolchain solo se serve compilare moduli, e usa un ambiente isolato solo quando la versione o le dipendenze lo impongono. Questa gerarchia ti evita di trasformare un interprete stabile in una sorgente continua di conflitti.

In sintesi operativa: il Perl di sistema è la base, la toolchain è il supporto, perlbrew è il separatore di contesti. Se li usi con criterio, su 22.04 e 24.04 il risultato è lo stesso: meno sorprese, meno manutenzione reattiva e più controllo sul ciclo di vita degli script.