Handbook:Parts/Portage/Advanced/it

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Handbook:Parts/Portage/Advanced and the translation is 9% complete.
Outdated translations are marked like this.

Per la maggior parte degli utenti, le informazioni comunicate finora sono sufficienti per tutte le loro operazioni su Linux. Ma Portage può fare molto di più; molte delle sue funzionalità sono per utenti esperti o applicabili solo in casi specifici e marginali. Tuttavia, ciò non vorrebbe essere una scusa per non documentarli.

Naturalmente, insieme a tanta flessibilità si accompagna un enorme elenco di casi potenziali. Non è possibile documentarli tutti qui. Piuttosto, intendiamo concentrarci su alcuni problemi generici che possono essere adattati alle esigenze personali. Maggiori trucchi e consigli si possono trovare sul Wiki di Gentoo.

La maggior parte, se non tutte le funzionalità aggiuntive, possono essere facilmente individuate cercando tra le pagine manuale fornite da Portage:

user $man portage
user $man make.conf

Infine, tener presente che si tratta di funzionalità avanzate che, se non gestite correttamente, possono rendere molto difficile il debug e la risoluzione dei problemi. Assicurarsi di menzionarle quando ci si imbatte in un bug e si apre un bug report (rapporto errori).

Variabili d'ambiente per pacchetto

Usare /etc/portage/env

Per impostazione predefinita, le compilazioni (build) dei pacchetti useranno le variabili d'ambiente definite in /etc/portage/make.conf, come CFLAGS, MAKEOPTS ed altre. In alcuni casi, tuttavia, potrebbe essere utile fornire variabili diverse per specifici pacchetti. Per fare ciò, Portage supporta l'uso di /etc/portage/env e /etc/portage/package.env.

Il file /etc/portage/package.env contiene l'elenco dei pacchetti per i quali sono necessarie variabili d'ambiente diversificate ed un identificatore specifico che indichi a Portage quali modifiche apportare. Il nome dell'identificatore è in formato libero e Portage cercherà le variabili nel file /etc/portage/env/IDENTIFIER.

Esempio: Usare il debug per pacchetti specifici

Come esempio, abiliteremo il debug per il pacchetto media-video/mplayer.

Prima di tutto, impostare le variabili di debug in un file chiamato /etc/portage/env/debug-cflags. Il nome è scelto arbitrariamente, ma certamente riflette la ragione della modifica per rendere più chiara, in seguito, quale modifica è stata inserita.

root #mkdir /etc/portage/env
FILE /etc/portage/env/debug-cflagsVariabili specifiche per il debug
CFLAGS="-O2 -ggdb -pipe"
FEATURES="${FEATURES} nostrip"

Poi, etichettiamo il pacchetto media-video/mplayer per usare questo contenuto:

FILE /etc/portage/package.envUsare debug-cflags per il pacchetto mplayer
media-video/mplayer debug-cflags

Agganci nel processo di compilazione

Usare /etc/portage/bashrc ed i file affiliati

Quando Portage lavora con gli ebuild, utilizza un ambiente bash in cui chiama le varie funzioni di build (come src_prepare, src_configure, pkg_postinst, ecc.). Ma Portage permette agli utenti di configurare anche un ambiente bash specifico.

Il vantaggio dell'utilizzo di un ambiente bash specifico consiste nel permettere agli utenti di collegarsi al processo di emerge (compilazione) durante ogni fase eseguita. Ciò può essere fatto per ogni compilazione (tramite /etc/portage/bashrc) o usando ambienti specifici per pacchetto (tramite /etc/portage/env come discusso in precedenza).

Portage calls so-called phase hook functions if they are defined in /etc/portage/bashrc. These functions follow the naming convention pre_phase_name and post_phase_name. For example, Portage will call the post_pkg_postinst hook just after calling the pkg_postinst phase function.

Per agganciarsi (inserirsi) nel processo, l'ambiente bash può ascoltare le variabili EBUILD_PHASE, CATEGORY così come le variabili che sono sempre disponibili durante lo sviluppo di ebuild (come P, PF, ... ). In base ai valori di queste variabili, è possibile eseguire aggiuntivi passaggi o funzioni.

Esempio: Aggiornare il database dei file

In questo esempio, useremo /etc/portage/bashrc per chiamare alcune applicazioni database di file per garantire che i loro database siano aggiornati rispetto al sistema. Le applicazioni usate nell'esempio sono aide (uno strumento di rilevamento delle intrusioni) e updatedb (da usare con mlocate), ma sono da intendersi come esempi. Non si consideri ciò come una guida per AIDE!

Per usare /etc/portage/bashrc in questo caso, dobbiamo "agganciare" alle funzioni postrm (dopo la rimozione dei file) e postinst (dopo l'installazione dei file), perché è in quel momento che i file sul file system risultano modificati.

FILE /etc/portage/bashrcAggancio alle fasi postinst e postrm
if [ "${EBUILD_PHASE}" == "postinst" ] || [ "${EBUILD_PHASE}" == "postrm" ];
then
  echo ":: Chiamare aide --update per aggiornare il suo database"
  aide --update
  echo ":: Chiamare updatedb per aggiornare il suo database"
  updatedb
fi

post_pkg_postinst() { my_database_update; } post_pkg_postrm() { my_database_update; } }}

Eseguire attività dopo --sync

Usare la posizione /etc/portage/postsync.d

Fino ad ora abbiamo parlato dell'aggancio ai processi di ebuild. Tuttavia, Portage ha anche un'altra importante funzione: aggiornare il repositorio di Gentoo. Per eseguire attività dopo l'aggiornamento del repositorio di Gentoo, inserire uno script all'interno di /etc/portage/postsync.d ed assicurarsi che sia contrassegnato come eseguibile.

Esempio: Eseguire eix-update

Se eix-sync non è stato usato per aggiornare l'albero, allora è ancora possibile aggiornare il database eix dopo aver eseguito emerge --sync (o emerge-webrsync) inserendo un link simbolico verso /usr/bin/eix chiamato eix-update dentro /etc/portage/postsync.d.

root #ln -s /usr/bin/eix /etc/portage/postsync.d/eix-update
Nota
Se viene scelto un nome diverso, allora deve essere uno script che chiama invece /usr/bin/eix-update. Il binario eix analizza come è stato chiamato per scoprire quale funzione deve eseguire. Se viene creato un collegamento simbolico che punta a eix quando ancora eix-update non è stato chiamato, non verrà eseguito correttamente.

Sovrascrivere le impostazioni del profilo

Usare /etc/portage/profile

In via predefinita, Gentoo utilizza le impostazioni contenute nel profilo a cui punta /etc/portage/make.profile (un collegamento simbolico alla corretta cartella del profilo). Questi profili definiscono sia impostazioni specifiche come anche ereditano impostazioni da altri profili (tramite il loro file genitore).

Usando /etc/portage/profile, gli utenti possono sovrascrivere le impostazioni del profilo come i pacchetti (cioè quali pacchetti si deve considerare siano parte del sistema), opzioni (flag) di uso forzato ed altro.

Esempio: aggiungere nfs-utils al sistema

Quando si utilizza un filesystem basato su NFS per filesystem piuttosto critici, potrebbe essere necessario marcare net-fs/nfs-utils come pacchetto di sistema, facendo in modo che Portage avvisi severamente gli amministratori se tentano di disinstallarlo.

Per soddisfare ciò, aggiungiamo il pacchetto a /etc/portage/profile/packages, preceduto da un *:

FILE /etc/portage/profile/packagesMarcare nfs-utils come pacchetto di sistema
*net-fs/nfs-utils

Applicare correzioni non standard

Patching source code using user patches in /etc/portage/patches/

User patches provide a way to apply patches to package source code when sources are extracted before installation. This can be useful for applying upstream patches to unresolved bugs, or simply for local customizations.

Patches need to be dropped into /etc/portage/patches/. They will automatically be applied during package installation.

Patches can be dropped into any of the following directories:

  • /etc/portage/patches/${CATEGORY}/${P}/ e.g. /etc/portage/patches/dev-lang/python-3.3.5-r1/
  • /etc/portage/patches/${CATEGORY}/${PN}/ e.g. /etc/portage/patches/dev-lang/python-3.4.2/
  • /etc/portage/patches/${CATEGORY}/${P}-${PR}/ e.g. /etc/portage/patches/dev-lang/python-3.3.5-r0/

Esempio: Applicare patch a Firefox

Il pacchetto www-client/firefox è uno dei tanti che chiama epatch_user già da dentro l'ebuild, quindi non c'è bisogno di sovrascrivere nulla di specifico.

Se per qualche motivo (per esempio uno sviluppatore ha fornito una correzione ed ha chiesto di verificare se è stato risolto l'errore segnalato) è necessario correggere Firefox, è sufficiente mettere la correzione (patch) in /etc/portage/patches/www-client/firefox (probabilmente è meglio usare il nome e la versione completi in modo che la patch non interferisca con le versioni successive) e ricompilare Firefox.