Guida per il porting a X Modulare

1.  Introduzione

Introduzione

Ci si può (giustamente) meravigliare se il comodo pacchetto xorg-x11 si è trasformato in almeno 300 pacchetti sepatati . Questo cambiamento non è qualcosa che Gentoo sta facendo indipendentemente dallo sviluppo di X.Org; gli sviluppatori di questo software stanno suddividendo tutti i pacchetti in versioni assestanti, e il gruppo degli sviluppatori di Gentoo sta seguendo la stessa modalità.

Si possono ottenere ulteriori dettagli nella Guida per la migrazione a X Modulare.

2.  Controllo delle dipendenze

Lo scopo è di enumerare le dipendenze nel modo più preciso possibile, affinchè agli utenti non vengano installati software inutili che non useranno mai, tipo XPrint. Perciò è necessario configurare le dipendenze direttamente alle librerie e ai file header necessari, invece che direttamente ad un qualche pacchetto virtual.

Inoltre, non si garantisce che gli utenti continueranno ad avere installati dei sottopacchetti solo perchè si ha un metapacchetto installato; eliminando questa potenziale fonte di problemi gli sviluppatori risparmieranno un sacco di tempo, altrimenti sprecato a marcare INVALID i bug.

Se viene trovato un pacchetto dipendente da uno qualsiasi dei metapacchetti esistenti, non si esiterà a stressare il suo manutentore per l'eternità.

Il primo passaggio è quello di installare X modulare o trovare qualcuno che ce l'abbia installato. Ciò può essere fatto in un ambiente chroot -- attualmente non c'è la necessità che X sia in esecuzione, basta che siano disponibili i suoi file per il controllo delle dipendenze.

$ wget http://dev.gentoo.org/~dberkholz/scripts/linking_libs \
  http://dev.gentoo.org/~dberkholz/scripts/included_headers \
  http://dev.gentoo.org/~betelgeuse/scripts/deputils/checkdeps.rb \
  http://dev.gentoo.org/~betelgeuse/scripts/deputils/pkgutil.rb

Il primo script, linking_libs, cerca nel log della compilazione del pacchetto tutte le librerie alla quale esso viene linkato, e stampa i pacchetti a cui le librerie appartengono. Per ottenere un log di compilazione, si può configurare opportunamente la variabile PORT_LOGDIR in /etc/make.conf o usare la ridirezione dell'output.

$ ls /var/log/portage/*gdm* -l
-rw-r--r-- 1 root portage 556551 2006-01-09 11:41 /var/log/portage/8430-gdm-2.8.0.7.log
-rw-r--r-- 1 root portage    855 2006-01-09 11:42 /var/log/portage/8431-gdm-2.8.0.7.log
$ linking_libs /var/log/portage/8430-gdm-2.8.0.7.log

Il secondo script, included_headers, effettua una ricerca, nei file sorgenti del pacchetto, delle linee che cominciano con #include, e restituisce gli include file contenuti in <>. Dal 9 Settembre 2005 la ricerca funziona anche con gli include del tipo "".

Il terzo script, checkdeps.rb, esamina i file installati appartenenti al pacchetto tramite il comando scanelf incluso in pax-utils. È utile nel caso di pacchetti binari o pacchetti che, diversamente da altri, nascondono l'output di compilazione. È uno script Ruby, per cui dipenderà sia da dev-lang/ruby come da app-misc/pax-utils. Il quarto script, pkgutil.rb, è una dipendenza di checkdeps.rb.

Eseguendo i primi due script si otterrà un discreto elenco di pacchetti da usare sia in RDEPEND (per le librerie) che in DEPEND (per header e librerie). Se una libreria compare nella lista per RDEPEND ma non in quella per DEPEND bisogna stare attenti: può essere una "falsa dipendenza" (una libreria che viene linkata senza motivi apparenti). Un esempio conosciuto di questo tipo di dipendenza avviene con libXt: diversi pacchetti cercano gli header di libXt per verificare l'esistenza di X.

Occasionalmente la ricerca relativa degli header in included_headers.sh troverà l'header sbagliato, perchè ce ne sono molti chiamati allo stesso modo, di conseguenza verrà restituito un pacchetto errato. Il verificarsi di questo errore è abbastanza ovvio, per esempio quando degli header per Windows fanno credere che app-emulation/wine sia una dipendenza.

Se si specifica l'opzione -d, occasionalmente una libreria o header verrà segnalato come "Not found!" (ndt "Non Trovato!"). Ciò significa che l'header richiesto dal pacchetto è stato rimosso a seguito della sua compilazione, o che l'header è opzionale e non lo si sta usando. Nel caso della libreria, significa che essa è stata disinstallata o forse era solamente una libreria statica compilata internamente che non è mai stata installata.

Vale la pena di perdere del tempo a capire quali librerie o header non trovate necessitano di essere inserite nella lista delle dipendenze, in particolar modo nel caso degli header siccome non occorre siano installati per effettuare la scansione.

In certi casi, i pacchetti richiedono un qualche tipo di server X di ultima generazione. Ma se effettivamente non lo richiedono in fase di installazione, viene incoraggiata la pratica di non inserirlo in RDEPEND. Questo rende problematica l'installazione di X su macchine headless, dove i programmi effettivamente sono in esecuzione su un'altra macchina per cui necessitano solo delle librerie locale e degli header.

Ci sono già un certo numero di server X nell'albero di Portage, per cui se si necessita di un server X, è consigliabile includerli tutti. I server X modulari sono in xorg-server; c'è un server DirectFB in xdirectfb; kdrive fornisce piccoli server X; ed ovviamente c'è il vecchio <xorg-x11-7. Si deve specificare la restrizione ella versione di xorg-x11, per assicurarsi di usare un server X invece di un metapacchetto. Prossimamente è previsto lo spostamento di kdriver in xserver. Se si ha necessità di un server X, si prega di contattare un membro del gruppo di X. Verrà creato un virtual se un sufficiente numero di pacchetti lo richiederà.

3.  Struttura delle dipendenze

Le dipendenze andranno strutturate nel seguente modo:

RDEPEND="|| ( ( x11-libs/libXfoo
		x11-libs/libXbar
		blah? ( x11-libs/libXblah )
		qualunque altra cosa mostrata nello script per le librerie
		)
		virtual/x11
	)

DEPEND="${RDEPEND}
	|| ( (  x11-proto/fooproto
		blah? ( x11-proto/blahproto )
		qualunque cosa elencato in entrambi gli script
		)
		virtual/x11
	)

L'obiettivo è di passare in modo predefinito al nuovo X modulare, lasciando comunque che i pacchetti degli utenti rispettino completamente le dipendenze con il vecchio, monolitico pacchetto xorg-x11. In futuro verrà completamente rimosso virtual/x11 per incoraggiare l'enumerazione delle dipendenze opportune.

Nella revisione iniziale dell'albero, il gruppo responsabile del porting sistemerà solamente gli ebuild più recenti disponibili per gli utenti ~arch, e tutti quelli ancora più nuovi (aventi KEYWORDS=-* o inclusi in package.mask). I manutentori di pacchetti individuali potranno scegliere di effettuare anch'essi queste operazioni e lasciare che gli ebuild di cui non è stato effettuato il porting escano gradualmente dall'albero, ma probabilmente vorranno effettuare il porting di tutti i loro ebuild in una volta sola. Repoman prossimamente si bloccherà irreversibilmente con ogni ebuild avente una qualsiasi dipendenza con virtual/x11.

4.  Come comportarsi con le flag USE

Molti utenti hanno la USE flag xinerama disattivata. Ma se, mentre si sta eseguendo included_headers, x11-proto/xineramaproto compare tra le dipendenze, si deve aggiungerla a DEPEND come voce condizionale alla USE xinerama, ed aggiungere x11-libs/libXinerama a RDEPEND come voce condizionale alla USE xinerama.

Caleb ha sollevato un'interessante questione, ovvero: come ci si comporta con tutte le flag USE dei pacchetti che hanno tonnellate di dipendenze opzionali alle librerie X? In molti casi, è più sensato forzare l'abilitazione o la disabilitazione delle flag. Inoltre, si può facilitare questa operazione raggruppando le flag. Ci si assicuri di nominare le flag in base alla loro funzione, e non in base alla libreria o al pacchetto che utilizzano.

5.  Far pervenire le correzioni nell'albero di Portage

Se si è uno sviluppatore, si deve effettuarne il commit. Altrimenti, inserire un bug, assegnandolo al manutentore del pacchetto (elencato in metadata.xml), aggiungerlo come dipendenza nell'apposito bug tracker #112675, e allegare una patch per correggere le dipendenze.

I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike.