Come installare RVM su Debian 11 Bullseye

Su Debian 11 Bullseye RVM funziona bene, ma va trattato come un componente di runtime, non come un semplice pacchetto “da installare e dimenticare”. La differenza la fanno tre aspetti: dipendenze corrette, verifica della chiave GPG e scelta consapevole tra installazione per utente e installazione di sistema. Se salti uno di questi punti, il risultato tipico è un ambiente Ruby che sembra pronto ma poi fallisce al primo gem install o al primo cambio di shell.

RVM su Debian 11: cosa conviene fare davvero

Se l’obiettivo è sviluppare o gestire più versioni di Ruby sullo stesso host, RVM resta una scelta pratica. Su Debian 11, però, conviene evitare installazioni improvvisate con script non verificati o con permessi troppo ampi. La procedura corretta parte da un sistema aggiornato, prosegue con i pacchetti necessari per compilare Ruby e termina con un controllo esplicito del caricamento della shell.

Prima decisione: installazione per utente o di sistema. Per un server condiviso o una workstation amministrata da più persone, la via per utente è spesso più sicura perché limita il blast radius. La via di sistema ha senso solo se sai esattamente chi deve usare RVM e vuoi centralizzare la gestione delle versioni Ruby. In entrambi i casi, il punto critico è lo stesso: RVM modifica il comportamento della shell e deve essere caricato correttamente in ogni sessione interattiva.

Prerequisiti su Debian 11 Bullseye

RVM compila Ruby da sorgente nella maggior parte degli scenari reali, quindi servono toolchain e librerie di sviluppo. Su Debian 11 il set base è questo:

sudo apt update
sudo apt install -y curl gnupg2 ca-certificates dirmngr \
  build-essential autoconf bison libssl-dev libyaml-dev \
  libreadline-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm-dev \
  libdb-dev

Il pacchetto dirmngr serve per la gestione della chiave GPG, mentre build-essential e le librerie di sviluppo coprono le dipendenze più comuni di Ruby. Se salti un header, il problema non emerge subito: lo vedi quando RVM tenta di compilare una versione specifica e la build si interrompe con un errore di configurazione o di linking.

Per verificare che il sistema sia coerente, controlla almeno architettura e release. Non è un passaggio decorativo: sulle macchine vecchie o ibride, una libreria mancante o una release non allineata produce errori che sembrano “problemi di RVM” ma sono semplicemente problemi di base OS.

cat /etc/debian_version
uname -m
lsb_release -a 2>/dev/null || cat /etc/os-release

Verifica della chiave GPG prima di installare RVM

La parte che non va saltata è la verifica della chiave. RVM distribuisce una chiave GPG da importare e usare per controllare il pacchetto. Se la chiave non è importata correttamente, l’installazione può fallire oppure, peggio, essere fatta bypassando il controllo. In un contesto amministrativo serio, quel bypass non è una scorciatoia: è un errore operativo.

Importa la chiave pubblica ufficiale e verifica l’esito. Il comando seguente è la base più comune su Debian 11:

gpg --keyserver keyserver.ubuntu.com --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3

gpg --keyserver keyserver.ubuntu.com --recv-keys 7D2BAF1CF37B13E2069D6956105BD0E739499BDB

Se il keyserver non risponde, non forzare il processo con un download non verificato. In quel caso il modo corretto per chiudere il gap è usare un canale alternativo affidabile o consultare la documentazione ufficiale del progetto per il fingerprint corrente. L’obiettivo non è “far partire l’installazione a tutti i costi”, ma validare che il materiale scaricato provenga dalla fonte prevista.

Per controllare cosa hai importato, usa:

gpg --list-keys

Qui non stai ancora installando nulla: stai solo verificando che la chiave sia presente e che la tua catena di fiducia sia in ordine. Se hai dubbi sulla chiave attesa, il campo da confrontare è il fingerprint mostrato nei riferimenti ufficiali del progetto, non il nome visualizzato da GPG.

Installazione di RVM su Debian 11 per utente singolo

La modalità più pulita è l’installazione per utente. Evita di contaminare il sistema globale e rende più semplice il rollback: basta rimuovere i file nella home dell’utente e ripristinare la shell. Sul piano operativo, è la scelta più sensata per ambienti di sviluppo e per server dove Ruby serve a uno o pochi account dedicati.

Scarica e avvia l’installer ufficiale solo dopo aver completato i prerequisiti. Il flusso tipico è questo:

curl -sSL https://get.rvm.io | bash -s stable

Questo comando è comodo, ma va trattato con prudenza: è un’esecuzione diretta da rete. Se il tuo standard operativo impone maggiore controllo, scarica prima lo script, ispezionalo e poi eseguilo. In un contesto di sicurezza più stretto, questa è la variante preferibile:

curl -sSL https://get.rvm.io -o /tmp/rvm-install.sh
less /tmp/rvm-install.sh
bash /tmp/rvm-install.sh stable

Dopo l’installazione, carica RVM nella sessione corrente. Su Bash, il file più comune è ~/.bashrc; su Zsh, ~/.zshrc. RVM può anche modificare i profili in modo automatico, ma conviene sempre verificare esplicitamente che il caricamento sia corretto.

source ~/.rvm/scripts/rvm
rvm --version

Se rvm --version risponde, la parte base è a posto. Se il comando non esiste, quasi sempre il problema è uno dei seguenti: shell non ricaricata, inizializzazione mancante nel file profilo, oppure installazione eseguita con un utente diverso da quello che stai usando adesso.

Configurazione della shell: il punto che crea più falsi positivi

Molti considerano RVM “rotto” quando in realtà non è stato inizializzato nella shell giusta. Questo succede spesso su Debian quando si apre una sessione non interattiva, si usa sudo per fare prove, oppure si passa da Bash a Zsh senza aggiornare il profilo corretto.

Per Bash, aggiungi o verifica queste righe in ~/.bashrc:

export PATH="$HOME/.rvm/bin:$PATH"
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"

Per Zsh, l’equivalente va in ~/.zshrc. Dopo la modifica, ricarica la shell o apri una nuova sessione:

exec bash
# oppure
exec zsh

Il controllo vero non è “il file è stato modificato”, ma “la shell vede RVM”. Verifica con:

type rvm
which rvm
rvm current

Se type rvm restituisce una funzione o un alias coerente, sei sulla strada giusta. Se restituisce “not found”, non ha senso andare avanti con Ruby: il layer di inizializzazione non è ancora corretto.

Installare una versione di Ruby con RVM

Una volta che RVM è caricato, il test utile è installare una versione precisa di Ruby. Non scegliere “l’ultima” in modo cieco: per ambienti applicativi conviene allinearsi alla versione richiesta dal progetto o dal framework. Il comportamento di compilazione e le gem native cambiano abbastanza da rendere importante la scelta esplicita.

rvm list known | head -n 20
rvm install 3.3.0
rvm use 3.3.0 --default

La riga rvm use 3.3.0 --default imposta quella versione come predefinita per l’utente. Se vuoi limitare il cambio alla sola sessione corrente, ometti --default. Questo è utile quando stai testando compatibilità senza voler toccare la configurazione permanente.

Subito dopo verifica il runtime effettivo:

ruby -v
gem -v
which ruby
which gem

L’output deve puntare al prefisso RVM, non al Ruby di sistema. Se which ruby continua a restituire /usr/bin/ruby, significa che il path o l’inizializzazione non sono ancora corretti, oppure che stai eseguendo il comando in un contesto non interattivo che non carica i profili della shell.

Installazione di gem e gestione delle dipendenze native

Su Debian 11, il punto dolente non è quasi mai RVM in sé, ma le gem con estensioni native. Se una gem richiede compilazione C, devi avere già presenti gli header e la toolchain. Quando manca qualcosa, l’errore compare in fase di bundle install o gem install, non durante l’installazione di RVM.

Un test utile è installare una gem semplice e una con dipendenze più pesanti, per esempio nokogiri o pg se il tuo stack lo richiede. Esempio:

gem install bundler
bundle -v
gem install nokogiri

Se la build fallisce, non partire subito con workaround casuali. Leggi il primo errore utile, non gli ultimi venti. In genere il messaggio indica chiaramente se manca una libreria di sviluppo, se il compilatore non è disponibile o se la versione di Ruby non è compatibile con quella gem.

Installazione di RVM in modalità system-wide: quando ha senso

La modalità di sistema è più delicata perché aumenta il raggio d’impatto delle modifiche. Ha senso solo se devi gestire più account con lo stesso set di Ruby e hai bisogno di una configurazione centralizzata. In questo caso è ancora più importante tenere traccia delle modifiche e prevedere un rollback semplice.

La procedura varia a seconda del setup, ma il principio resta lo stesso: installazione con privilegi amministrativi, configurazione del gruppo dedicato, verifica dell’accesso ai binari e controllo della shell per ogni utente coinvolto. Se non hai già un motivo preciso per farlo, la soluzione per utente è quasi sempre preferibile.

Un controllo minimale da fare dopo una configurazione centralizzata è questo:

rvm info
rvm user gemsets
rvm gemdir

Qui verifichi dove RVM sta tenendo gemset e versioni, così da evitare installazioni duplicate o conflitti tra utenti. Se il risultato non è quello previsto, il problema non è “Ruby che non parte”, ma una policy di accesso o un path non coerente.

Problemi tipici su Debian 11 e come leggerli

Ci sono alcuni errori ricorrenti che vale la pena riconoscere al volo. Il primo è la mancanza della chiave GPG o un fingerprint non valido: in quel caso l’installazione si ferma prima di iniziare davvero. Il secondo è la compilazione di Ruby che fallisce per librerie mancanti. Il terzo è la shell che non carica RVM e ti fa credere che l’installazione sia fallita, quando in realtà è solo invisibile alla sessione corrente.

Per distinguere questi casi, usa sempre una piccola sequenza di verifica: stato della shell, versione di RVM, versione di Ruby e path dei binari. Esempio:

type rvm
rvm --version
ruby -v
which ruby
env | grep '^GEM_'

Se type rvm è corretto ma ruby -v mostra ancora il Ruby di sistema, il problema è quasi sempre il caricamento del profilo o l’ordine del PATH. Se invece rvm install fallisce, la causa è più probabilmente a livello di dipendenze o toolchain.

Disinstallazione e rollback pulito

La parte che molti dimenticano è il rollback. Con RVM per utente, il ripristino è semplice: rimuovi il blocco di inizializzazione dai file di shell, elimina ~/.rvm e riapri la sessione. Prima di farlo, però, assicurati che non ci siano progetti che dipendono da quella versione Ruby.

rvm list
rvm gemset list
rm -rf ~/.rvm

Il comando rm -rf qui è potenzialmente distruttivo e va usato solo se hai già confermato che non ti servono più versioni, gemset o configurazioni locali. In un contesto più prudente, fai prima un backup della directory e verifica che i progetti usino un’altra toolchain prima di rimuovere tutto.

Se hai installato RVM in modo centralizzato, il rollback deve includere anche la pulizia dei profili utente, dei gruppi o dei permessi aggiunti per l’accesso condiviso. In quel caso il blast radius è più ampio e conviene documentare ogni modifica fatta, così da poter tornare indietro senza lasciare residui.

Checklist operativa finale

Se vuoi una verifica rapida e concreta dopo l’installazione, usa questa sequenza minima:

1. Conferma i prerequisiti: build-essential, librerie SSL, readline, zlib e GPG presenti con dpkg -l | grep -E 'build-essential|libssl-dev|libreadline-dev|zlib1g-dev|dirmngr'.
2. Verifica la chiave importata con gpg --list-keys e confronta il fingerprint con la fonte ufficiale.
3. Installa RVM con il metodo scelto e ricarica la shell con source ~/.rvm/scripts/rvm.
4. Controlla che type rvm e which ruby puntino ai percorsi attesi.
5. Installa una versione Ruby precisa e prova ruby -v e gem install bundler.

Assunzione: su Debian 11 Bullseye vuoi un’installazione RVM usabile in modo affidabile, con shell interattiva correttamente inizializzata e possibilità di rollback rapido senza toccare il Ruby di sistema.