GNOME 50 (Fedora 44, Ubuntu 26.04) rimuove l'integrazione con Google Drive (aggiornato: 2 aprile 2026, ore 07:28)

Chi utilizza il l'ambiente desktop (DE) GNOME per accedere ai file su Google Drive direttamente dal gestore file si prepari a un brusco risveglio. Con GNOME 50, l'integrazione nativa con Google Drive scompare. Niente più cartelle cloud che appaiono come se fossero locali, niente più trascinamento di file tra il proprio disco e lo spazio Google. La causa è tecnica e, a dire il vero, annunciata da tempo: la libreria che rendeva possibile tutto questo non ha più nessuno che se ne occupi.

La morte silenziosa di libgdata

Al centro della questione c'è libgdata, la libreria che si occupa dell'interazione con i servizi online di Google all'interno dell'ecosistema GNOME. Dopo essere rimasta senza un manutentore attivo per quasi quattro anni, a dicembre 2022 uno sviluppatore GNOME aveva pubblicato un appello pubblico: serviva qualcuno disposto a prendersene cura. Nessuno si è fatto avanti.

Il risultato è che libgdata è stata archiviata. Non semplicemente abbandonata - proprio archiviata su GitLab, il che significa che anche chi volesse contribuire con una correzione oggi non potrebbe farlo sul repository ufficiale. Il progetto è, a tutti gli effetti, congelato.

C'è poi un aspetto tecnico che rende la rimozione ancora più comprensibile, se non inevitabile. libgdata dipendeva da libsoup2, una versione ormai obsoleta della libreria HTTP di GNOME. Tenerla in vita significava trascinare questa dipendenza antiquata, bloccando miglioramenti in altre parti del software. Come ha spiegato uno sviluppatore GNOME: «Portava con sé dipendenze antiche nel nostro stack software, bloccando miglioramenti in altre parti dell'infrastruttura».

Come si è arrivati qui

La rimozione non è stata un colpo di scena. Circa dieci mesi prima del rilascio di GNOME 50, GVFS - il filesystem virtuale di GNOME, quello che permette al gestore file di montare anche risorse remote come se fossero cartelle locali - aveva già disabilitato la dipendenza da libgdata come impostazione predefinita. Una merge request nel repository di GVFS ha sancito il distacco. Parallelamente, GNOME Online Accounts (GOA) è stato aggiornato per verificare lo stato di questa dipendenza: se GVFS non la include, il toggle per i permessi di accesso ai file di Google Drive semplicemente non compare più nelle impostazioni.

Graduale, trasparente, documentato. La trasparenza, però, non attenua l'impatto pratico.

Cosa funziona ancora e cosa no

L'integrazione con Google non è scomparsa del tutto. Chi aggiunge un account Google in GNOME Online Accounts continuerà ad avere accesso a posta elettronica, contatti e calendario - questi servizi non dipendevano da libgdata e restano perfettamente funzionanti.

Quel che si perde è l'accesso ai file di Google Drive. L'interruttore per i permessi di Drive nelle impostazioni dell'account Google non esiste più. Il gestore file non mostra alcuna cartella Google Drive. Per chi aveva costruito il proprio flusso di lavoro attorno a questa integrazione - aprire documenti, spostare file, gestire archivi - è una regressione concreta.

Un dettaglio importante: le integrazioni con OneDrive e Nextcloud non sono toccate. Il problema riguarda esclusivamente Google Drive.

Chi sarà colpito e quando

L'impatto si distribuirà a cascata sulle distribuzioni man mano che adotteranno GNOME 50.

Fedora 44, che includerà GNOME 50, è già in fase beta senza accesso a Google Drive dal gestore file.

Lo stesso dicasi per l'imminente Ubuntu 26.04 LTS.

Linux Mint nella versione attuale (Zara 22.2) utilizza ancora una vecchia versione di GVFS che include il supporto a Google Drive. Ma si tratta di codice non più mantenuto a monte. Quando Mint o Ubuntu aggiorneranno GVFS attraverso i repository upstream, l'integrazione sparirà - a meno che non venga confezionato un pacchetto separato.

Situazione analoga per le versioni di prossima uscita delle altre distribuzioni che utilizzino GNOME come DE.

E adesso?

Al momento non vi sono soluzioni pratiche. Lo stesso sviluppatore che aveva scritto l'appello ha precisato: «Non ha senso contattare il manutentore di GVFS a meno che non intendiate fare un fork e mantenere libgdata. Il mio appello di dicembre 2022 non era uno scherzo. È passato così tanto tempo che libgdata è stata archiviata, quindi non potete contribuire nemmeno volendo».

La strada è una sola: qualcuno deve prendersi la responsabilità di un fork di libgdata, aggiornarlo per eliminare la dipendenza da libsoup2, e mantenerlo nel tempo. Un lavoro non banale, che richiede competenze specifiche e soprattutto costanza.

In alternativa, chi ha le capacità tecniche può in teoria compilare versioni locali dal codice esistente, ma è una soluzione individuale, non scalabile.

Per tutti gli altri, le alternative sono poco entusiasmanti: utilizzare Google Drive dal browser, oppure strumenti di terze parti per sincronizzazione e backup, nessuno dei quali offre un'integrazione grafica nativa e gratuita paragonabile a quella appena persa.

CUB3 ha ricordato nei commenti l'opzione di sfruttare il programma "rclone":

» Leggi: rclone: il coltellino svizzero per la gestione degli spazi cloud

Il nodo strutturale

La vicenda di libgdata è emblematica di un problema ricorrente nell'ecosistema del software libero. Un componente critico per l'esperienza utente dipende dal lavoro volontario di pochi - a volte di uno solo. Quando quella persona si ferma, il componente inizia a deteriorarsi. Se nessuno raccoglie il testimone entro un tempo ragionevole, la rimozione diventa l'unica scelta responsabile. Tenere codice non mantenuto, con dipendenze obsolete, è un rischio per la sicurezza e un freno per lo sviluppo.

Gli sviluppatori GNOME hanno fatto la cosa giusta dal punto di vista ingegneristico. Il risultato pratico, però, è che il desktop Linux perde un pezzo di integrazione con uno dei servizi di archiviazione cloud più popolari, proprio mentre la percezione di "Linux pronto per l'uso quotidiano" stava guadagnando terreno.

Per chi usa Google Drive come deposito principale dei propri file, l'unica risposta oggi è aprire una scheda del browser - esattamente come si faceva dieci anni fa.

Fonti: Omgubuntu, Discourse Gnome, Reddit