Introduzione

Ubuntu fornisce una notevole quantità di pacchetti software ma a volte, per problematiche legate alle policy e a fattori esterni, non è possibile includere un determinato nuovo pacchetto o un aggiornamento di un'applicazione già presente negli archivi. Per risolvere il problema, diversi utenti si affidano a pacchetti fatti in casa o a repository di terze parti, i quali risolvono una lacuna ma rischiano di arrecare al sistema più danni che benefici.

In questo documento si analizzeranno le situazioni in cui è facile incappare utilizzando software non distribuito da Ubuntu, insieme ai potenziali rischi e problemi più comuni. Il consiglio è quello di rileggere con attenzione questa pagina durante un aggiornamento di alcuni pacchetti per diagnosticare velocemente eventuali problemi introdotti.

I contenuti sono anche rivolti a coloro interessati alla pacchettizzazione di software in modo da fornire accorgimenti utili ad alcuni problemi di difficile diagnosi.

Toolchain

Ogni distribuzione GNU/Linux, e Ubuntu non fa eccezione, comprende alcuni software essenziali per il corretto funzionamento del kernel e dell'intero parco software. L'insieme di questi software viene definito toolchain ed è la base sulla quale viene sviluppata una distribuzione. In Debian e Ubuntu, i pacchetti sorgente che formano la toolchain sono i seguenti:

• gcc-defaults (gcc, g++, ...)

• gdb

• glibc (libc6)

• binutils

Ognuno di questi pacchetti è indispensabile per il corretto funzionamento del sistema e del kernel; una rimozione accidentale o un aggiornamento non autorizzato può provocare l'instabilità permanente del sistema e perdita di dati. Gli aggiornamenti di questi pacchetti devono essere necessariamente rilasciati dagli sviluppatori di Ubuntu, per nessuna ragione è consigliabile utilizzare versioni provenienti da terze parti, a meno di non ricompilare ogni pacchetto per la nuova toolchain, il cui processo richiede giorni e giorni di lavoro.

Politiche di aggiornamento

Anche gli sviluppatori non possono rilasciare un aggiornamento che comporti una ricompilazione dell'intero parco software, ci si limita a singoli bugfix che non comportano cambiamenti sostanziali nella struttura dei pacchetti. Le funzionalità abilitate, le opzioni di compilazione e i parametri non possono essere rivisti per nessun motivo.

Librerie

Le librerie sono strumenti importanti in una distribuzione GNU/Linux perchè permettono a più programmi di avere un'interfaccia comune a una o più funzioni. Nelle distribuzioni derivate da Debian (come Ubuntu), il ruolo delle librerie è ancora più importante e delicato.

Processo di compilazione dei pacchetti

Gran parte dei pacchetti distribuiti da Ubuntu ha come dipendenze una o più librerie. Esse vengono generate automaticamente dal processo di creazione del pacchetto sulla base delle dipendenze di compilazione, indicate nel campo Build-depends: del pacchetto sorgente. Il pacchetto risultante si aspetta di trovare la versione della libreria sulla base della quale è stato compilato.

Si supponga che la libreria venga aggiornata ad una nuova versione. Il pacchetto deve necessariamente essere ricompilato per poter usufruire della nuova libreria. Un esempio pratico è dato dal bug #73722, nel quale il pacchetto openmcu non è stato ricompilato dopo l'aggiornamento della libreria libpt, rendendo di fatto inusabile il software in questione.

La policy di Debian dice che...

La policy di Debian, il documento di riferimento per gli sviluppatori di Debian e Ubuntu, tratta nel capitolo 8 lo spinoso problema della gestione dei pacchetti di libreria. In particolare, l'aggiornamento di una libreria richiede di rinominare il pacchetto, siccome la policy richiede espressamente che il SONAME della libreria venga rispettato nel nome del pacchetto (si veda la footnote #45 in merito).

Problemi derivanti dall'aggiornamento

Si veda ora questo messaggio di errore relativo al pacchetto exaile (bug #129816):

Traceback (most recent call last):
  File "exaile.py", line 44, in <module>
    import gtk, gtk.glade, pango, dbus
  File "/var/lib/python-support/python2.5/gtk-2.0/gtk/__init__.py", line 48, in <module>
    from gtk import _gtk
  File "/usr/lib/python2.5/site-packages/cairo/__init__.py", line 1, in <module>
    from _cairo import *
ImportError: /usr/lib/python2.5/site-packages/cairo/_cairo.so: undefined symbol: cairo_clip_extents

In questo caso l'aggiornamento di libcairo, una libreria grafica utilizzata dal desktop manager di GNOME, ha messo in crisi ogni singola applicazione scritta in Python a causa di un duplice errore di pacchettizzazione:

1. cattivo posizionamento: la libreria è stata posizionata in /usr/local/lib invece che nella canonica /usr/lib.

2. mancata transizione: la versione della libreria è differente rispetto a quella usata per la compilazione dei pacchetti e non si è provveduto ad una ricompilazione dei software che da essa dipendevano (in questo caso, 180 pacchetti).

Come aggiornare le librerie

Nel caso sia necessario utilizzare una libreria aggiornata rispetto a quella fornita da Ubuntu, è consigliabile la sua installazione manuale nella directory /usr/local/lib, mantenendo intatta la versione corrente per evitare problemi di compatibilità con le altre applicazioni.

Singoli pacchetti

L'aggiornamento di un singolo pacchetto non è causa di forti preoccupazioni dato che gli eventuali problemi sono circoscritti ad una singola applicazione, ma è comunque poco piacevole vedere il proprio software preferito chiudersi inaspettatamente e non riuscire a venirne a capo.

I problemi più comuni legati alla pacchettizzazione di singoli pacchetti sono i seguenti

1. librerie errate: a volte i pacchetti non vengono compilati usando software sicuri quali pbuilder, bensì compilati direttamente su un sistema al quale possono essere state aggiunte librerie differenti da quelle distribuite ufficialmente da Ubuntu. I sintomi di questo problema sono errori quali undefined symbol in fase di avvio o crash dell'applicazione durante il suo utilizzo. I motivi di ciò sono spiegati nella sezione precedente.

2. cattivo posizionamento: un pacchetto deve rispettare la posizione canonica dei file, definito dal Filesystem Hierarchy Standard, in caso contrario potrebbero venir meno alcune funzionalità o insorgere problemi di varia natura.

I numeri di versione dei pacchetti

Un problema ampiamente diffuso è la distribuzione di pacchetti con numeri di versione che possono confliggere con quelli distribuiti da Ubuntu. Si supponga che il pacchetto foo_0.1-0ubuntu1 sia ufficialmente distribuito e la versione 0.2-0ubuntu1 venga resa disponibile in un repository di terze parti. nel caso in cui Ubuntu decidesse di distribuire la nuova versione, si verrebbe ad utilizzare lo stesso numero di versione per due pacchetti differenti. Per ovviare a questo problema, la soluzione migliore è usare il simbolo della tilde (~) nella versione, in modo che la versione del pacchetto diventi 0.2-0ubuntu1~mypackage1.

Analisi di un caso limite

Oltre al numero di versione, per effettuare l'aggiornamento si tiene conto anche del timestamp, il quale rappresenta la data di creazione del pacchetto espresso in numero di secondi trascorsi dalla Unix Epoch (1 gennaio 1970). Si supponga che il pacchetto foo_0.1-0ubuntu1, che dipende da libc6, sia appena stato inserito nella versione di sviluppo con timestamp 1000 (semplificazione) e che pochi giorni dopo ne venga realizzato un backport non ufficiale con la stessa versione e timestamp 1100. Durante l'aggiornamento di Ubuntu alla versione successiva, il pacchetto foo non viene considerato siccome ha la medesima numerazione e il timestamp è maggiore. Eseguendo l'applicazione, è molto facile imbattersi in crash inspiegabili dato che è stato compilato usando la toolchain della precedente versione stabile.

Note sull'aggiornamento di release

Come ultimo accorgimento, è consigliabile rimuovere i repository di terze parti e i pacchetti da essi forniti durante un aggiornamento di distribuzione (per esempio, da Ubuntu 10.04 a Ubuntu 10.10). Per fare ciò, è sufficiente agire sul file /etc/apt/sources.list rimuovendo le righe non relative a repository ufficiali di Ubuntu o usando il seguente comando:

sudo sed -i '/archive.ubuntu.com/!d' /etc/apt/sources.list

Una volta effettuata questa operazione e ricaricato l'elenco dei pacchetti (con il comando sudo apt-get update), è possibile rimuovere i pacchetti non ufficiali con un qualsiasi gestore di pacchetti.
Synaptic elenca tali pacchetti sotto la categoria Installato (locale o obsoleto).
Ubuntu Software Center elenca tali pacchetti sotto la categoria Installato → Sconosciuto.

CategoryAmministrazione