3 modi per installare Perl su Ubuntu 24.04 o 22.04

Su Ubuntu 22.04 e 24.04 hai tre modi sensati per arrivare a Perl installato e usabile, ma non sono equivalenti. Il pacchetto di sistema è la scelta più pulita per server e automazione. perlbrew serve quando devi affiancare più versioni senza sporcare il sistema. Compilare da sorgente ha senso solo se hai un requisito preciso su patch, opzioni di build o versioni non ancora disponibili nei repository.

La decisione giusta dipende da una domanda semplice: vuoi un interprete stabile, integrato con gli aggiornamenti di Ubuntu, oppure vuoi controllare tu la versione e l’ambiente? Se non hai un vincolo esplicito, la risposta corretta è quasi sempre la prima. Se invece gestisci script legacy, tool di sviluppo o pipeline che richiedono versioni diverse, conviene separare bene il runtime di sistema da quello dell’utente o del progetto.

1) Installare Perl dai repository Ubuntu

Questa è la via standard. Installa l’interprete, i moduli essenziali e le dipendenze che Ubuntu mantiene e aggiorna con il ciclo di security update. Su 22.04 e 24.04 il pacchetto principale è perl, e in genere basta per far girare script, utility e applicazioni che non richiedono versioni custom.

Prima verifica cosa hai già nel sistema:

perl -v

Se il comando non esiste, oppure vuoi riallinearti ai pacchetti ufficiali, installa così:

sudo apt update
sudo apt install perl

Per i casi più comuni è utile aggiungere anche gli strumenti di compilazione dei moduli Perl in formato CPAN, perché molti moduli distribuiti come sorgenti richiedono una toolchain minima:

sudo apt install build-essential make

Se lavori con moduli che compilano codice nativo, puoi trovarti a dover installare librerie di sviluppo specifiche. L’elenco dipende dal modulo, quindi il punto corretto non è “installare tutto”, ma leggere il log del build e aggiungere solo i pacchetti mancanti. In pratica: il messaggio di errore del compilatore ti dice quasi sempre quale header o libreria manca.

Dopo l’installazione, controlla versione e path dell’eseguibile:

which perl
perl -v

Su Ubuntu il binario di sistema di solito si trova in /usr/bin/perl. Questo dettaglio conta quando hai più installazioni nello stesso host: se un cron, un servizio systemd o uno script punta a un path diverso, rischi di eseguire una versione diversa da quella che pensi.

2) Installare Perl con perlbrew per gestire più versioni

Se devi mantenere versioni diverse di Perl sullo stesso server, perlbrew è la soluzione più pulita. Non sostituisce il Perl di sistema: crea un ambiente utente separato e ti permette di passare da una versione all’altra senza toccare i pacchetti di Ubuntu. È la scelta giusta per sviluppo, test, build farm o ambienti dove convivono applicazioni con requisiti differenti.

Prima installa le dipendenze minime:

sudo apt update
sudo apt install curl build-essential perl

Poi installa perlbrew nel tuo account utente. Il metodo più comune è lo script ufficiale:

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

Questa operazione modifica i file della shell dell’utente, in genere in ~/.perlbrew e nel profilo della shell. Se usi bash, ricarica l’ambiente:

source ~/perl5/perlbrew/etc/bashrc

Il percorso può variare in base alla versione dello script installatore, quindi se il file non esiste controlla il messaggio finale dell’installazione o il contenuto della directory home dell’utente. Il punto importante è che l’inizializzazione della shell deve avvenire prima di usare i comandi di perlbrew.

Per vedere le versioni disponibili:

perlbrew available

Per installare una versione specifica, per esempio una 5.38.x o 5.40.x, usa:

perlbrew install perl-5.40.1

Quando l’installazione è finita, attiva la versione appena creata:

perlbrew switch perl-5.40.1

Verifica subito che il binario corretto sia quello in uso:

which perl
perl -v
perlbrew list

Il vantaggio operativo è netto: puoi tenere il Perl di sistema intatto e usare versioni diverse per progetti diversi. Il rovescio della medaglia è che devi governare bene il contesto della shell. Uno script lanciato da cron, da systemd o da un job CI non eredita automaticamente l’ambiente interattivo, quindi se dipende da una versione di perlbrew devi inizializzare esplicitamente il path o usare il path assoluto del binario.

Un esempio concreto: se hai uno script legacy che gira bene con una vecchia 5.30 e un nuovo tool che richiede 5.40, con perlbrew puoi gestire entrambi senza cambiare i pacchetti di Ubuntu. Questo evita la classica situazione in cui un aggiornamento di sistema rompe un’applicazione vecchia solo perché dipende da un comportamento specifico dell’interprete.

3) Compilare Perl da sorgente quando serve davvero

Compilare Perl da sorgente non è il metodo da usare per “avere l’ultima versione” in modo generico. È sensato quando devi applicare opzioni di build particolari, validare una release specifica, testare patch o installare una versione che non vuoi ottenere tramite pacchetto o perlbrew. Qui il punto critico è il rischio operativo: una compilazione fatta male può sovrascrivere binari, librerie o path che altri servizi si aspettano invariati.

Prima di procedere, identifica chiaramente dove vuoi installare l’interprete. La pratica corretta è usare un prefisso dedicato, non sovrascrivere il Perl di sistema. Per esempio /opt/perl-5.40.1 o una directory in home se si tratta di un test personale.

Installa le dipendenze minime:

sudo apt update
sudo apt install build-essential wget tar

Scarica il sorgente dalla distribuzione ufficiale Perl. Esempio con una release specifica:

wget https://www.cpan.org/src/5.0/perl-5.40.1.tar.gz
tar -xzf perl-5.40.1.tar.gz
cd perl-5.40.1

Configura la build con un prefisso separato:

./Configure -des -Dprefix=/opt/perl-5.40.1

Se vuoi fare una build conservativa, non aggiungere opzioni inutili. Il valore di default è spesso migliore di una configurazione “creativa” fatta per abitudine. Dopo la configurazione, compila e installa:

make
make test
sudo make install

Il passaggio make test non è opzionale se stai installando per un server o per un ambiente che deve essere affidabile. Se i test falliscono, hai già un segnale utile prima di mettere in produzione il binario. In caso di errore, il log di build e la directory dei test ti dicono quasi sempre se il problema è una libreria mancante, una patch incompatibile o un ambiente sporco.

Per usare la build installata senza toccare il sistema, punta esplicitamente al nuovo binario:

/opt/perl-5.40.1/bin/perl -v

Se vuoi integrarlo nella shell dell’utente, aggiorna PATH in modo locale e reversibile, per esempio in ~/.profile o in un file dedicato caricato solo per quel progetto. Evita modifiche globali a /etc/profile o a file di sistema se non stai standardizzando un’intera piattaforma.

Quale metodo scegliere in pratica

Se il server deve ospitare script standard, scegli i pacchetti Ubuntu. È il percorso con meno attrito operativo, meno manutenzione e migliore integrazione con gli aggiornamenti di sicurezza. Se lavori su più progetti con requisiti diversi, usa perlbrew per isolarli. Se devi controllare il processo di build o validare una versione in un contesto molto specifico, compila da sorgente, ma solo in un prefisso separato.

Una regola utile è questa: il Perl di sistema serve per l’infrastruttura, il Perl gestito dall’utente serve per i progetti, il Perl compilato a mano serve per casi eccezionali. Confondere i tre livelli è il modo più rapido per creare incidenti difficili da diagnosticare, perché un aggiornamento apparentemente innocuo può cambiare il binario eseguito da cron, da un servizio o da uno script di deploy.

Controlli dopo l’installazione

Dopo qualsiasi metodo, verifica sempre tre cose: versione, percorso del binario e moduli disponibili. Sono i tre punti che ti dicono se stai usando davvero il Perl che volevi.

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

Se il comando which perl mostra un path inatteso, hai quasi certamente un conflitto tra pacchetto di sistema, perlbrew e eventuali installazioni manuali. Se il problema compare solo in cron o in systemd, il sospetto principale è l’ambiente non inizializzato, non il binario in sé. In quel caso la correzione è nel file unit o nello script di avvio, non nel pacchetto.

Per i moduli, il controllo minimo è installarne uno noto e verificare che il loader funzioni. Se il tuo progetto usa dipendenze specifiche, meglio testare direttamente quelle invece di fermarti a un semplice perl -v. La versione dell’interprete da sola non dice se il resto dello stack Perl è coerente.

Errori tipici da evitare

Il primo errore è installare più versioni senza una regola chiara per il path. Il secondo è compilare in /usr/local senza sapere cosa c’è già. Il terzo è dare per scontato che la shell interattiva e l’esecuzione automatica usino lo stesso ambiente. In realtà spesso non è così, e proprio lì nascono i bug più fastidiosi.

Un altro errore comune è ignorare i log di build. Quando un modulo fallisce, il messaggio utile è quasi sempre dentro l’output completo, non nella riga finale che riassume il fallimento. Se compili Perl o moduli CPAN su un server, conserva il log almeno fino alla verifica finale: è la tua unica traccia affidabile se qualcosa non torna.

Infine, non usare il metodo “più veloce” solo perché sembra più immediato. Su un host di produzione la differenza tra un’installazione pulita da repository e una build manuale si misura in ore di manutenzione risparmiate, non in minuti guadagnati oggi.

Mini sintesi operativa

Se vuoi una risposta secca: usa sudo apt install perl per il server, usa perlbrew per gestire più versioni in modo ordinato, compila da sorgente solo quando hai un motivo tecnico preciso e un prefisso separato. Tutto il resto è rumore operativo.