GNOME package guidelines (Italiano)

I pacchetti GNOME di Arch Linux seguono un determinato schema.

Profilo di inizializzazione di GNOME

Non c'è più alcun profilo di inizializzazione. La vecchia riga dovrebbe essere eliminata da ogni PKGBUILD:

[ -z "$GNOMEDIR" ] && . /etc/profile.d/gnome.sh

Schemi GConf

Molti pacchetti GNOME installano schemi Gconf. Questi schemi vengono installati nel database del sistema GConf, che andrebbe evitato. Alcuni pacchetti mettono a disposizione l'opzione --disable-schemas-install per il ./configure, che spesso non funziona. Per questo motivo gconftool-2, possiede una variabile chiamata GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL, se questa viene impostata, gconftool-2 non aggiornerà alcun database. Nel creare pacchetti che installano file schema, utilizzare

make GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 DESTDIR=${pkgdir} install

nello stage di installazione del pacchetto.

È necessario installare e rimuovere gli schemi GConf nel file .install, utilizzando pre_remove(), pre_upgrade(), post_upgrade() e post_install(). Utilizzare gconf-merge-schemas per unire diversi schemi in unico file specifico per uno pacchetto, installarli o disinstallarli tramite usr/sbin/gconfpkg --(un)install $pkgname. L'utilizzo di gconfpkg richieda la dipendenza gconf>=2.18.0.1-4 (or gconfmm>=2.20.0).

Schemi GSettings

Gli schemi Gconf verranno rimpiazzati dagli schemi Gsettings in un futuro molto prossimo, anche se alcune applicazioni li usano già (ad es. Empathy). Il sistema GSettings utilizza dconf come backend, perciò ogni pacchetto che contiene schemi GSettings deve avere dconf come dipendenza. Quando viene installato un nuovo schema GSettings sul sistema, il database GSettings deve essere rigenerato, ciò non deve accadere invece durante la fase di pacchettizzazione. Per evitare che avvenga la rigenerazione del database GSettings durante la pacchettizzazione, utilizzare lo switch --disable-schemas-compile sul ./configure. Per ricompilarlo al momento dell'installazione, aggiungere le righe seguenti al file .install nel blocco post_install, post_upgrade e post_remove: glib-compile-schemas usr/share/glib-2.0/schemas

Scrollkeeper e la documentazione

A partire da GNOME 2.20 non vi è più la necessità di utilizzare Scrollkeeper, in quanto Rarian legge direttamente i file OMF. Scrollkeeper-update è quindi un'abitudine superata, ormai. L'unico requisito è la soddisfazione della dipendenza di compilazione gnome-doc-utils>=0.11.2.

File .desktop

Molti pacchetti installano file .dektop compatibili con le specifiche di Freedesktop.org, e registrano chiavi MimeType al loro interno. L'esecuzione di update-desktop-database -q all'interno del post_install() e del post_remove() è raccomandata (il pacchetto dovrebbe dipendere da desktop-file-utils in questo caso)

Cache delle icone GTK

Alcuni pacchetti installano le proprie icone all'interno del tema hicolor. Questi pacchetti dovrebbero dipendere da hicolor-icon-theme e dovrebbero eseguire gtk-update-icon-cache -q -t -f usr/share/icons/hicolor nelle funzioni post_install(), post_upgrade() e post_remove().

File .install

Per molti pacchetti GNOME, i file .install sono esattamente identici. Il pacchetto gedit contiene un file .install molto generico. https://projects.archlinux.org/svntogit/packages.git/tree/gedit/repos/extra-i686/gedit.install^{[link interrotto 2021-11-10]}

Fondamentalmente, l'unica cosa che deve essere modificata è la variabile pkgname in cima al file .install. Visto che pacman non fornisce il nome del pacchetto come variabile, dovremo fornirlo noi nel file .install. Nel caso il pacchetto non contenesse schemi GConf, icone per il tema hicolor, o file .desktop, si possono tranquillamente rimuovere le parti che gestiscono questi ultimi.

Esempio

Per un esempio delle regole citate, consultare il PKGBUILD del pacchetto gedit con relativo file .install fornito al seguente indirizzo: https://projects.archlinux.org/svntogit/packages.git/tree/gedit/repos/extra-i686/^{[link interrotto 2021-11-10]}