Installare l'ultima versione di R su Debian 11 Bullseye

Su Debian 11 Bullseye, il punto non è solo installare R, ma farlo in modo che il sistema prenda una versione recente senza mischiare pacchetti in modo casuale. La differenza la fa quasi sempre il repository usato: i pacchetti della distribuzione sono stabili ma spesso indietro, mentre il repository ufficiale di CRAN ti dà una versione più nuova, purché il sistema sia configurato con criterio.

Il caso tipico è questo: hai un server Bullseye già in produzione, vuoi una versione recente di R per analisi, Shiny, automazione o pipeline dati, e non vuoi trascinarti dietro dipendenze incoerenti. Qui l’obiettivo è semplice: usare il repository giusto, verificare la firma, installare il pacchetto corretto e controllare che il runtime sia quello atteso.

Perché il pacchetto di default non basta quasi mai

Debian privilegia la stabilità del ramo. Su Bullseye questo significa che la versione di R disponibile nei repository standard può non essere quella che ti serve per pacchetti recenti, bugfix o compatibilità con librerie moderne. Se lavori con pacchetti CRAN aggiornati, una versione vecchia di R può diventare il collo di bottiglia più velocemente di quanto sembri.

La strada corretta, nella maggior parte dei casi, è usare il repository CRAN dedicato alla release Debian/Ubuntu compatibile. Su Bullseye il vantaggio è doppio: versioni più fresche e aggiornamenti allineati al ciclo di CRAN, senza dover compilare tutto a mano. La compilazione manuale ha senso solo se ti serve una build completamente personalizzata o una versione non ancora disponibile nei binari.

Prerequisiti tecnici e verifica del contesto

Prima di toccare i repository, verifica tre cose: versione del sistema, architettura e stato dei repository già presenti. Questo ti evita di infilare un repo non adatto o di scoprire dopo che stai lavorando su un host misto o con policy di pinning già attive.

Esegui questi controlli:

cat /etc/debian_version
uname -m
apt-cache policy r-base

Se il sistema è davvero Bullseye, il primo comando deve riflettere il ramo 11.x. Il secondo ti dice se sei su amd64, arm64 o altro. Il terzo mostra da dove arriverebbe r-base oggi e ti aiuta a capire se stai già pescando da repository esterni.

Se non hai ancora una baseline pulita, conviene salvare anche lo stato attuale dei pacchetti coinvolti:

dpkg -l | grep -E '^ii\s+(r-base|r-recommended|r-cran-)'
apt-mark showhold

Il secondo comando è utile perché un hold su r-base o su dipendenze collegate può bloccare l’aggiornamento senza errori evidenti a colpo d’occhio.

Repository CRAN corretto per Bullseye

La configurazione più pulita passa dal file dedicato in /etc/apt/sources.list.d/. Evita di sporcare il file principale se non hai una ragione precisa: è più facile fare audit, rollback e confronto tra ambienti.

Prima installa i prerequisiti per la gestione delle chiavi e del trasporto HTTPS:

sudo apt update
sudo apt install -y --no-install-recommends dirmngr gnupg ca-certificates apt-transport-https

Su Debian recente apt-transport-https può essere già superfluo, ma lasciarlo in questo contesto non rompe nulla; se il pacchetto non esiste o è virtuale, il sistema lo gestisce senza drammi. Il punto importante è avere gnupg e ca-certificates in ordine.

Ora aggiungi la chiave e il repository CRAN. Il metodo consigliato è usare una keyring dedicata, non il vecchio approccio con apt-key, che oggi è da considerare deprecato per nuovi setup.

sudo mkdir -p /usr/share/keyrings
curl -fsSL https://cloud.r-project.org/bin/linux/debian/marutter_pubkey.asc | gpg --dearmor | sudo tee /usr/share/keyrings/cran.gpg > /dev/null

echo "deb [signed-by=/usr/share/keyrings/cran.gpg] https://cloud.r-project.org/bin/linux/debian bullseye-cran40/" | sudo tee /etc/apt/sources.list.d/cran-r.list

Il suffisso bullseye-cran40/ è quello tipicamente usato per Bullseye. Se in futuro la mappatura del repository cambia, non forzare l’ipotesi: verifica sempre la pagina CRAN per Debian e il nome esatto della directory. Qui il gap si chiude controllando il contenuto del repo e non andando a memoria.

Subito dopo, aggiorna l’indice pacchetti e controlla che il repository venga visto correttamente:

sudo apt update
apt-cache policy r-base

Nell’output di apt-cache policy devi vedere il candidato proveniente da CRAN e non solo quello di Debian. Se il repository non compare, il problema è quasi sempre uno tra: URL errato, chiave non accettata, o file di source scritto male.

Installazione della versione più recente di R

A questo punto l’installazione è lineare. Il pacchetto base è r-base; se ti servono gli strumenti di sviluppo, aggiungi r-base-dev.

sudo apt install -y r-base r-base-dev

Se vuoi una installazione più minimale, puoi partire solo da r-base. Se invece devi compilare pacchetti R con dipendenze C, Fortran o librerie di sistema, r-base-dev è praticamente obbligatorio.

Controlla subito quale versione è stata installata:

R --version
Rscript --version
apt-cache policy r-base-core

Il primo comando è quello che ti interessa davvero: la release mostrata deve corrispondere alla versione recente del ramo CRAN per Bullseye. Il secondo serve come controllo ulteriore del binario. Il terzo ti conferma che il pacchetto base proviene dalla source attesa.

Dipendenze di sistema che saltano fuori dopo l’installazione

Il punto critico non è quasi mai R in sé, ma i pacchetti R che installerai dopo. Su server puliti, alcune librerie di sistema emergono solo quando provi a compilare un package o a caricare un modulo che usa grafica, SSL, XML, geospaziale o database.

Le dipendenze più comuni da avere a portata di mano su Bullseye sono queste:

sudo apt install -y build-essential libcurl4-openssl-dev libssl-dev libxml2-dev libjpeg-dev libpng-dev libtiff5-dev libfontconfig1-dev

Non installarle alla cieca su ogni host: il criterio giusto è aggiungerle quando sai che il tuo carico di lavoro le richiede. Se il server deve solo eseguire script batch con pacchetti già compilati, puoi restare più leggero. Se invece compili spesso da CRAN, meglio prepararne una base coerente.

Per pacchetti che usano database o parsing specifici, i dev package cambiano. Esempi tipici: libpq-dev per PostgreSQL, libmariadb-dev per MariaDB/MySQL, libudunits2-dev e libgdal-dev per stack geospaziali. Il criterio è sempre lo stesso: installa solo ciò che serve al tuo set di pacchetti.

Verifica funzionale con un test reale

Installare R e fermarsi alla versione stampata non basta. Il controllo utile è fare una sessione minima e verificare che il runtime sia stabile, che possa scrivere su libreria utente e che la risoluzione dei pacchetti funzioni.

R --vanilla

Dentro la console R, esegui:

sessionInfo()
.libPaths()
install.packages("jsonlite", repos = "https://cloud.r-project.org")
library(jsonlite)
jsonlite::toJSON(list(status = "ok"), auto_unbox = TRUE)

Il test con jsonlite è pratico perché è piccolo, diffuso e abbastanza utile da smascherare problemi di rete, CA certificates, compilazione o path delle librerie. Se l’installazione si ferma per mancanza di permessi, il problema è spesso nella directory utente o in una policy di sistema che blocca la scrittura in ~/R.

Se vuoi evitare interattività, usa Rscript:

Rscript -e 'print(R.version.string); print(.libPaths())'

Per ambienti automatizzati è il controllo più utile, perché puoi metterlo in un job di provisioning o in una pipeline di validazione post-deploy.

Se qualcosa non torna: lettura rapida dei sintomi

Se apt update fallisce con errore di firma, controlla prima la chiave e poi l’URL del repository. Il sintomo tipico è una riga tipo “NO_PUBKEY” oppure “repository is not signed”. In quel caso la verifica da fare è immediata:

apt-cache policy
cat /etc/apt/sources.list.d/cran-r.list
ls -l /usr/share/keyrings/cran.gpg

Se il repository è presente ma r-base continua a venire dal ramo Debian, allora hai quasi sempre un problema di priorità o un repo non raggiungibile. In quel caso il controllo più rapido è confrontare la versione candidata e la source list:

apt-cache policy r-base
grep -R "cran" /etc/apt/sources.list /etc/apt/sources.list.d/

Se invece l’installazione parte ma R non compila pacchetti, guarda i log dell’installazione e i messaggi di build. I file da osservare sono quelli del terminale e, per installazioni di pacchetti utente, la directory temporanea e i messaggi di configure. Quando fallisce una dipendenza nativa, il messaggio quasi sempre cita la libreria mancante: non andare a tentativi, installa esattamente il dev package richiesto.

Gestione del rollback senza fare danni

Se hai bisogno di tornare indietro, il rollback deve essere banale. Il vantaggio di usare un file separato per il repository è proprio questo: puoi disabilitarlo senza toccare il resto della configurazione APT.

sudo mv /etc/apt/sources.list.d/cran-r.list /etc/apt/sources.list.d/cran-r.list.disabled
sudo apt update

Se vuoi rimuovere anche i pacchetti installati da CRAN, fallo con cautela e solo dopo aver verificato cosa dipende da R:

apt-cache rdepends r-base-core
sudo apt remove --purge r-base r-base-dev

Qui il blast radius è chiaro: togli R dal sistema e potresti rompere script, cron job, servizi Shiny, tool di data processing o automazioni che lo usano. Prima di rimuovere, verifica i consumer reali e salva eventuali script o ambienti virtuali associati.

Quando conviene fermarsi e compilare da sorgente

La compilazione da sorgente non è il percorso standard, ma ha senso in tre casi: ti serve una patch specifica, vuoi un build target diversa, oppure il repository binario non è disponibile per il tuo scenario architetturale. In tutti gli altri casi è solo lavoro in più e più superficie di errore.

Se decidi di compilare, fallo in un ambiente controllato e con una directory di installazione separata, non sovrascrivendo i pacchetti di sistema alla cieca. Il rischio qui è la divergenza: una R compilata a mano può convivere male con librerie di sistema, soprattutto se poi aggiorni il sistema via APT senza un controllo preciso delle dipendenze.

Per la maggior parte degli host Debian 11, però, la soluzione robusta resta la stessa: repository CRAN corretto, chiave gestita con keyring dedicata, installazione di r-base e verifica con test reale. È un percorso semplice, ma solo se lo fai con disciplina.

Checklist finale operativa

Prima di chiudere il lavoro, passa questa sequenza:

Se una di queste verifiche fallisce, non saltare direttamente a modifiche invasive. Prima identifica il layer rotto: repository, firma, rete, pacchetto o dipendenza nativa. È il modo più veloce per arrivare a una installazione pulita e ripetibile su Debian 11 Bullseye.