Come installare Visual Studio Code su Debian

Installare Visual Studio Code su Debian senza sporcare il sistema

Su Debian la strada più lineare è usare il repository ufficiale di Microsoft, non il pacchetto scaricato a mano e nemmeno installazioni improvvisate con dipendenze lasciate in giro. Così ottieni aggiornamenti coerenti con il resto del sistema, disinstallazione semplice e un controllo più chiaro su firma e provenienza del software.

La logica è questa: aggiungi una sorgente APT dedicata, importi la chiave di firma nel formato corretto, aggiorni l’indice pacchetti e installi code. Se poi vuoi tenere il parco software ordinato, puoi decidere se usare il canale stabile o, in casi particolari, il canale insiders. Qui resto sullo stabile, che è quello sensato per un desktop o una workstation di lavoro.

Prima di toccare il sistema, conviene verificare due cose: la versione di Debian e la presenza di APT funzionante. Se APT è rotto o il sistema è in uno stato incoerente, aggiungere un repository esterno non aiuta; anzi, complica il debug. Il punto di partenza deve essere un host aggiornabile con privilegi amministrativi.

Prerequisiti e controllo rapido dell’ambiente

Apri un terminale e verifica versione, architettura e connettività verso i mirror. Non serve essere pignoli per sport: serve capire subito se la piattaforma è compatibile e se il problema eventuale sarà di rete, DNS o pacchetti.

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

Su una macchina standard ti aspetti un’architettura amd64 o, in alcuni casi, arm64. Visual Studio Code è disponibile per le architetture comuni, ma se sei su un sistema molto particolare conviene verificare prima la disponibilità del pacchetto. Se apt-cache policy mostra errori di repository già prima della procedura, risolvili prima di aggiungere il nuovo feed.

Se lavori su una macchina remota o gestita in team, è una buona abitudine fare un backup del file di configurazione APT che stai per creare. Qui il blast radius è basso, ma una modifica fatta male al file sorgente può bloccare gli aggiornamenti futuri. Il rollback, in questo caso, è semplicemente rimuovere il file aggiunto e rilanciare apt update.

Aggiungere il repository ufficiale di Microsoft

Il metodo corretto oggi è usare la directory /etc/apt/keyrings e non il vecchio schema con apt-key, ormai da considerare una cattiva abitudine. L’obiettivo è limitare la fiducia della chiave al repository specifico, non spargerla globalmente nel trust store APT.

La sequenza pratica è questa:

sudo apt update
sudo apt install -y wget gpg ca-certificates
sudo install -d -m 0755 /etc/apt/keyrings
wget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor | sudo tee /etc/apt/keyrings/microsoft.gpg > /dev/null
sudo chmod 0644 /etc/apt/keyrings/microsoft.gpg

Qui ci sono due verifiche da fare. La prima è che il file /etc/apt/keyrings/microsoft.gpg esista ed abbia permessi leggibili da APT. La seconda è che il download della chiave non fallisca per problemi di rete o TLS. Se il comando con wget non restituisce nulla e gpg produce errore, non forzare: controlla prima proxy, DNS o certificati locali.

A questo punto aggiungi la sorgente APT. Il formato moderno con signed-by è quello giusto, perché lega il repository alla chiave appena importata.

echo "deb [arch=amd64,arm64 signed-by=/etc/apt/keyrings/microsoft.gpg] https://packages.microsoft.com/repos/code stable main" | sudo tee /etc/apt/sources.list.d/vscode.list

Se sei su una sola architettura, puoi restringere arch al valore effettivo del sistema. Non è obbligatorio, ma riduce rumore e rende più chiaro il comportamento del resolver APT. Su una workstation Debian standard, amd64 basta quasi sempre.

Verificare la sorgente prima dell’installazione

Prima di installare il pacchetto, aggiorna gli indici e guarda se APT vede davvero il repository di VS Code. Questo passaggio evita di scoprire eventuali errori solo nel mezzo di apt install, quando il messaggio può essere più confuso.

sudo apt update
apt-cache policy code

Il risultato atteso è che apt update completi senza errori di firma e che apt-cache policy code mostri una candidata proveniente da packages.microsoft.com. Se invece vedi un problema di tipo NO_PUBKEY, la chiave non è stata importata correttamente o il file non è leggibile. Se compare un errore di release non valida, controlla l’URL del repository e la riga scritta in /etc/apt/sources.list.d/vscode.list.

In caso di rete aziendale filtrata, è normale che il repository esterno venga bloccato dal proxy o dal firewall. Il sintomo tipico è un timeout o un errore di connessione durante apt update. In quel caso il problema non è Debian né VS Code: devi far passare il dominio packages.microsoft.com o usare un mirror consentito dalla policy interna.

Installazione del pacchetto VS Code

Quando il repository è visibile, l’installazione è banale. Il pacchetto si chiama code e porta con sé le integrazioni desktop standard, così da avere anche il launcher grafico e l’associazione corretta nel menu applicazioni.

sudo apt install -y code

Se usi una sessione grafica, puoi avviare l’editor dal menu oppure da terminale con code. Un controllo utile è verificare la versione installata, così sai subito quale ramo hai in macchina e puoi confrontarlo con la release attesa.

code --version

Il comando restituisce in genere tre righe: versione, commit e architettura. È un dettaglio utile quando devi aprire un ticket o confrontare il comportamento tra due workstation. Se l’avvio grafico non parte ma il pacchetto è installato, il problema spesso è nella sessione X11/Wayland o nelle variabili d’ambiente, non nel pacchetto in sé.

Avvio, integrazione desktop e primo controllo funzionale

La prima apertura serve a verificare che il binario parta, che il profilo utente venga creato e che l’integrazione con il desktop funzioni. Non saltare questo passaggio: molte installazioni “formalmente riuscite” falliscono poi per problemi di sessione, permessi su $HOME o librerie grafiche mancanti.

code

Se parte correttamente, al primo avvio puoi aspettarti la schermata iniziale con scelta del tema e alcune impostazioni base. Se invece il processo termina subito, lancia l’editor da terminale e osserva l’output. In molti casi il messaggio utile è già nel terminale, soprattutto se manca un componente grafico o un’estensione di sistema non compatibile.

Per un controllo più tecnico, puoi verificare dove si trova il binario e quale pacchetto lo fornisce. È una verifica utile anche quando ci sono più installazioni o residui di vecchi pacchetti.

which code
apt list --installed | grep '^code/'

Se which code punta a un percorso strano, come un wrapper in /usr/local/bin, potresti avere installazioni parallele. In quel caso conviene pulire la versione duplicata prima di dare per buona quella nuova. La regola è semplice: un solo binario nel PATH, un solo gestore del pacchetto, zero ambiguità.

Aggiornamenti e manutenzione nel tempo

Con il repository configurato, VS Code seguirà gli aggiornamenti di sistema. Questo è il vantaggio principale rispetto al pacchetto manuale: non devi ricordarti di scaricare ogni volta una nuova build, e soprattutto non rompi la coerenza con il meccanismo APT del sistema.

La verifica periodica è la solita:

sudo apt update
apt list --upgradable | grep code

Se vuoi aggiornare in modo controllato, puoi farlo insieme al resto del sistema durante una finestra di manutenzione. Su una workstation personale il rischio è minimo; su una macchina condivisa o amministrata in remoto, però, ha senso leggere prima il changelog della versione nuova se stai usando estensioni critiche o integrazioni particolari.

Per disinstallare, la procedura è reversibile e pulita. Il blast radius è limitato al software editor e al repository dedicato, a meno che tu non abbia già usato estensioni e impostazioni utente che vuoi preservare. In quel caso i dati di configurazione restano nel profilo utente e non vengono rimossi dal pacchetto.

sudo apt remove -y code
sudo rm -f /etc/apt/sources.list.d/vscode.list
sudo rm -f /etc/apt/keyrings/microsoft.gpg
sudo apt update

Se vuoi rimuovere anche le impostazioni locali, devi intervenire sul profilo utente, tipicamente sotto ~/.config/Code e ~/.vscode. Fallo solo se è davvero voluto: lì dentro ci sono preferenze, estensioni e dati che spesso vale la pena conservare. In ambiente aziendale, prima di cancellare, è meglio sapere se l’utente ha bisogno di un backup o di una migrazione verso una nuova macchina.

Problemi frequenti e come leggerli senza perdere tempo

Il primo errore tipico è la chiave mancante o messa nel posto sbagliato. Il secondo è il repository scritto male, spesso per una copia-incolla incompleta. Il terzo è la rete che blocca il download. In tutti e tre i casi, il modo più rapido per non andare a tentoni è leggere l’output esatto di apt update e controllare il file sorgente.

Comandi utili per il debug:

cat /etc/apt/sources.list.d/vscode.list
ls -l /etc/apt/keyrings/microsoft.gpg
sudo apt update 2>&1 | tee /tmp/apt-vscode.log

Se il file sorgente contiene un URL errato, correggilo e rilancia apt update. Se il problema è la chiave, ricreala con gpg --dearmor. Se il problema è la rete, non perdere tempo a reinstallare pacchetti: devi prima risolvere accesso, proxy o DNS. Un repository esterno non funziona mai meglio del tuo stack di rete.

Un caso meno ovvio è la presenza di più repository che forniscono pacchetti con nomi simili. In quel caso apt-cache policy code ti dice da dove arriverebbe l’installazione e quale priorità ha ciascuna sorgente. È la verifica giusta quando vuoi evitare di installare una build non prevista o di mischiare canali diversi.

Quando conviene non usare il pacchetto .deb manuale

Scaricare il file .deb e installarlo con dpkg -i sembra comodo, ma alla lunga è la scelta peggiore se il sistema deve restare aggiornato e riproducibile. Ti ritrovi a gestire dipendenze a mano, a dimenticare gli aggiornamenti e a creare differenze inutili tra una macchina e l’altra.

Il repository ufficiale, invece, ti lascia una traccia chiara nel sistema: un file in /etc/apt/sources.list.d/, una chiave in /etc/apt/keyrings/ e un pacchetto gestito da APT. È la soluzione più pulita anche se devi documentare la procedura per altri operatori o replicarla su più workstation Debian.

Se devi standardizzare l’ambiente, puoi persino trasformare questi passaggi in uno script di bootstrap o in una configurazione gestita via Ansible. In quel caso conserva sempre il principio base: keyring separato, repository dedicato, installazione verificabile. È un dettaglio piccolo, ma in manutenzione fa la differenza tra una procedura leggibile e una serie di eccezioni difficili da auditare.

Verifica finale minima

Dopo l’installazione, il controllo minimo che mi aspetto è questo: repository presente, chiave leggibile, pacchetto installato, avvio grafico funzionante. Se uno di questi quattro punti manca, non dare per conclusa la procedura.

grep -R "packages.microsoft.com/repos/code" /etc/apt/sources.list.d/
ls -l /etc/apt/keyrings/microsoft.gpg
apt list --installed | grep '^code/'
code --version

Se tutto torna, hai un’installazione pulita e mantenibile. Se invece qualcosa non quadra, la sequenza di debug è ancora la stessa: sorgente APT, chiave, rete, installazione, avvio. Non serve inventare percorsi alternativi quando quello standard è già sufficiente e più sicuro.