Ormai sono parecchi anni che lavoro come programmatore amatoriale, e quindi il punto di vista del programmatore già lo conosco da tempo.
Invece da un po’ di tempo mi sto dilettando anche come packager, anche se non è propriamente il caso di Gentoo parlare di packagers, visto che non si usano pacchetti veri e propri. Per chi non lo sapesse, un packager è una persona che prepara i pacchetti di installazione delle applicazioni per le varie distribuzioni.
Di solito questo significa preparare vari pacchetti a seconda delle varie impostazioni a build-time, risolvere le dipendenze (ovvero indicare quali pacchetti sono necessari per compilare od eseguire l’applicazione impacchettata), e quindi rilasciare il pacchetto.
In gentoo, il problema è ridotto, perché non esistono pacchetti precompilati, ma bisogna solo scrivere uno script che abbia indicate le dipendenze di build e di esecuzione, e nel caso ci siano delle feature abilitabili/disabilitabili a buildtime, inserire delle use-flag, che permettano appunto di abilitarle o disabilitarle a scelta.
Per fare questo, in genere basta inserire delle piccole funzioncine che vadano a richiamare ./configure con i giusti parametri.
Purtroppo non tutti i pacchetti definiscono correttamente il ./configure, non inserendo tutti gli switch per le feature opzionali, oppure inserendoli ma non “rinforzandoli”, ovvero anche se si chiede di disabilitare una determinata opzione, questa viene abilitata se viene trovato il pacchetto necessario.
Su gentoo KDE ha dei pacchetti un po’ strani, ovvero sono presenti assieme tutti i pacchetti di un determinato modulo CVS, quindi si tratta di macro-pacchetti contenenti molte applicazioni diverse. Il problema sarà risolto prima o poi, si spera.
Gnome invece ha la fortuna di impacchettare i sorgenti libreria per libreria e quindi da questo punto di vista è molto più semplice da gestire. Purtroppo però, le dipendenze di gnome sono abbastanza incasinate.
Sì perché gnome non usa metodi normali e portabili per verificare le dipendenze, come fa invece KDE, o qualsiasi altro pacchetto, ma usa invece pkg-config, a cui passa semplicemente le dipendenze necessarie.
Però se questo può andar bene per le dipendenze veramente necessarie senza cui non è possibile effettuare il build del pacchetto, per i pacchetti opzionali la cosa diventa un vero casino.
Il motivo è abbastanza semplice: se una dipendenza opzione viene attivata anche se con le flag di gentoo è stato chiesto di disabilitarla, nel momento in cui il pacchetto da cui questa dipende viene disinstallato, tutte le librerie e gli eseguibili che hanno linkato il pacchetto rimosso non possono più funzionare perché non riescono a risolvere alcuni simboli.
Per esempio a me è capitato un problema simile con arts, che non rinforza la disabilitazione di esound (pacchetto gnome). Nel momento in cui l’ho disinstallato, metà KDE non poteva essere eseguito perché era linkato ad arts che a sua volta era linkato ad esd rimosso.
Per risolvere questi problemi in genere bisogna andare a modificare lo script di configurazione per disabilitare quelle feature obbligatoriamente, oppure fornirgli un valore “cache” fasullo, in modo che lui creda che il pacchetto non c’è.
Questo funziona per tutti i pacchetti che usano le dipendenze standard. Per nota di cronaca, su KDE il problema si manifesta solo su arts.
Purtroppo Gnome grazie a pkg-config non è così semplice da prendere in giro, quindi c’è un bug aperto su Gentoo riguardo Esound necessario alle librerie Gnome, fin dal 2002. Per mio esperimento, è possibilissimo compilare le librerie gnome senza esound.
Tra le altre cose, visto che uso principalmente KDE, ho voluto rimuovere alcuni pacchetti come per esempio gnome-icon-theme e hicolor-icon-theme, nonché gnome-themes. Questi pacchetti sono relativamente le icone di gnome, delle icone generiche e i temi visivi di gnome.. tutti i temi visivi disponibili per Gnome.
Il motivo per cui ho voluto disinstallarli è abbastanza semplice: non usando gnome, ma usando gtk-qt per i pochi programmi che mi richiedono i temi gtk2, non ho bisogno né dei temi, né delle icone (gtk-qt fornisce automaticamente quelle di KDE), e quindi non mi pareva il caso di sprecare spazio per loro. Purtroppo però, c’erano dei pacchetti che volevano per forza di cose installarmele, e sono finito con il fargli dire che erano presenti anche se non era la verità.
Ieri tra le varie librerie che mi si sono presentate da aggiornare c’erano anche libgnomeprint e libgnomeprintui. La prima si è compilata e installata senza il minimo problema.. la seconda invece durante la fase di configurazione si è fermata chiedendomi di installare gnome-icon-theme (che a sua volta, tentandolo di installare, richiedeva hicolor-icon-theme). Arrabbiato da questa necessità di un tema di icone (che non può in nessun caso pregiudicare il codice compilato), mi sono insospettito e sono andato a guardare il codice del file di configurazione.
Ovviamente gnome-icon-theme era stato inserito sui check necesasri a pkg-config, e un piccolo commento subito sopra la richiesta lo classificava come ugly per mantenere i packager al loro posto, e quindi obbligarli a dipendere da gnome-icon-theme.
Questa è una vera e propria presa per i fondelli, visto che gnome-icon-theme non pregiudica alcun tipo di funzionalità in libgnomeprintui, e non dovrebbe essere necessario a questo. Per fortuna riuscire a modificare lo script di configurazione è stato abbastanza semplice, ed ho rilasciato un aggiornamento del mio ebuild pack con dentro una nuova ebuild per libgnomeprintui che non dipende in alcun modo da gnome-icon-theme.
Questo è un nuovo motivo per cui non mi piace Gnome: i developer hanno inserito delle dipendenze fasulle solo per rendere più complesso il lavoro dei programmatori e infastidire gli utenti finali che non volessero usare un ambiente 100% gnome.
Vorrei ricordare che KDE può benissimo essere usato senza arts, basta compilare tutti i pacchetti con –without-arts.
GNOME -= 1
KDE += 1
