Handbook:SPARC/Working/Portage/it
Benvenuto su Portage
Portage è una delle più notevoli innovazioni di Gentoo per la gestione del software. Grazie alla sua grande flessibilità e all'enorme quantità di caratteristiche, è considerato spesso il miglior strumento di gestione del software disponibile per Linux.
Portage è scritto completamente in Python e Bash e di conseguenza è completamente visibile agli utenti in quanto entrambi sono linguaggi di script.
La maggior parte degli utenti lavorerà con Portage tramite lo strumento emerge. Questo capitolo non è pensato per duplicare le informazioni disponibili tramite la pagina man di emerge. Per un resoconto completo delle opzioni di emerge, per favore si consulti la pagina man:
user $man emergeIl repositorio di Gentoo
Ebuild
Quando la documentazione di Gentoo parla di pacchetti, intende i titoli dei software che sono disponibili per gli utenti di Gentoo attraverso il repositorio di Gentoo (repository). Questo repositorio è una raccolta di ebuild, ovvero file che contengono tutte le informazioni di cui Portage necessita per mantenere il software (installazioni, ricerche, interrogazioni, ecc.). Queste ebuild risiedono normalmente nel percorso /usr/portage.
Ogni qual volta qualcuno chiede a Portage di effettuare un'azione riguardante i titoli del software, userà come base le ebuild nel sistema. Di conseguenza, è importante aggiornare regolarmente le ebuild, così che Portage venga a conoscenza del nuovo software, degli aggiornamenti di sicurezza, ecc.
Aggiornare il repositorio di Gentoo
Il repositorio di Gentoo è solitamente aggiornato tramite rsync, una veloce utilità di trasferimento file incrementale. L'aggiornamento è piuttosto semplice in quanto il comando emerge fornisce un front-end (interfaccia utente) per rsync:
root #emerge --syncTalvolta vengono applicate restrizioni tramite firewall tali da impedire a rsync di contattare i mirror. In questo caso, si aggiorni il repositorio di Gentoo tramite le istantanee (snapshot) di Gentoo generate quotidianamente. Lo strumento emerge-webrsync preleva ed installa automaticamente l'istantanea più recente sul sistema:
root #emerge-webrsyncManutenzione del software
Ricerca del software
Ci sono vari modi per cercare del software nel repositorio di Gentoo. Un modo è tramite emerge stesso. In via predefinita, emerge --search restituisce i nomi dei pacchetti il cui titolo corrisponde (completamente o parzialmente) al termine di ricerca inserito.
Per esempio, per cercare tutti i pacchetti che contengono "pdf" nel loro nome:
user $emerge --search pdfPer cercare anche nelle descrizioni, usare l'opzione --searchdesc (o -S):
user $emerge --searchdesc pdfSi noti che l'output restituisce molte informazioni. I campi sono chiaramente etichettati perciò non approfondiremo il loro significato:
* net-print/cups-pdf
Latest version available: 2.6.1
Latest version installed: [ Not Installed ]
Size of files: 33 KiB
Homepage: http://www.cups-pdf.de/
Description: Provides a virtual printer for CUPS to produce PDF files
License: GPL-2
Installazione del software
Quando un titolo di un software viene trovato, allora l'installazione dista giusto ad un comando di emerge. Per esempio, per installare gnumeric:
root #emerge --ask app-office/gnumericPoiché molte applicazioni dipendono l'una dall'altra, qualunque tentativo di installare un certo software potrà anche comportare l'installazione di numerose dipendenze. Non serve preoccuparsene, Portage gestisce bene le dipendenze. Per scoprire cosa installerebbe Portage, aggiungere l'opzione --pretend. Per esempio:
root #emerge --pretend gnumericTo do the same, but interactively choose whether or not to proceed with the installation, add the --ask flag:
root #emerge --ask gnumericDurante l'installazione di un pacchetto, Portage scaricherà il codice sorgente necessario da Internet (se necessario) e lo conserverà su /usr/portage/distfiles/. Dopodiché spacchetterà, compilerà ed installerà il pacchetto. Per dire a Portage di scaricare solamente i sorgenti senza installarli, aggiungere l'opzione --fetchonly al comando emerge:
root #emerge --fetchonly gnumericTrovare la documentazione dei pacchetti installati
Molti pacchetti possiedono una loro documentazione. Talvolta, l'opzione USE doc determina se la documentazione di un pacchetto debba essere installata oppure no. Per vedere se l'opzione USE doc viene usata da un certo pacchetto, usare emerge -vp category/package:
root #emerge -vp media-libs/alsa-libThese are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-libs/alsa-lib-1.1.3::gentoo USE="python -alisp -debug -doc" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python2_7" 0 KiB
Il miglior modo per abilitare l'opzione USE doc per un certo pacchetto è tramite /etc/portage/package.use, così che venga installata solo la documentazione per i pacchetti voluti. Per ulteriori informazioni, consultare la sezione Opzioni USE del manuale.
Una volta installato il pacchetto, la sua documentazione si trova generalmente in una sotto cartella presente su /usr/share/doc/ e nominata con il nome del pacchetto:
user $ls -l /usr/share/doc/alsa-lib-1.1.3total 16 -rw-r--r-- 1 root root 3098 Mar 9 15:36 asoundrc.txt.bz2 -rw-r--r-- 1 root root 672 Mar 9 15:36 ChangeLog.bz2 -rw-r--r-- 1 root root 1083 Mar 9 15:36 NOTES.bz2 -rw-r--r-- 1 root root 220 Mar 9 15:36 TODO.bz2
Un modo più sicuro per elencare i file della documentazione installati è usare l'opzione --filter di equery. equery viene usato per interrogare il database di Portage ed è parte del pacchetto app-portage/gentoolkit:
user $equery files --filter=doc alsa-lib* Searching for alsa-lib in media-libs ... * Contents of media-libs/alsa-lib-1.1.3: /usr/share/doc/alsa-lib-1.1.3/ChangeLog.bz2 /usr/share/doc/alsa-lib-1.1.3/NOTES.bz2 /usr/share/doc/alsa-lib-1.1.3/TODO.bz2 /usr/share/doc/alsa-lib-1.1.3/asoundrc.txt.bz2
L'opzione --filter può essere usata con altre regole per vedere i percorsi di installazione di molti altri tipi di file. Ulteriori funzionalità sono documentate nella pagina man di equery: man 1 equery.
Rimozione del software
Per rimuovere il software da un sistema, usare emerge --unmerge. Ciò dirà a Portage di rimuovere dal sistema tutti i file installati da quel pacchetto. Un'eccezione a ciò sono tutti i file di configurazione di quell'applicazione "se" sono stati modificati dall'utente. Lasciare i file di configurazione permette agli utenti di continuare a lavorare con il pacchetto senza bisogno di riconfigurarlo se viene reinstallato successivamente.
root #emerge --unmerge gnumericQuando un pacchetto viene rimosso dal sistema, le dipendenze di quel pacchetto che sono state installate automaticamente quando era stati installato vengono lasciate intatte nel sistema. Per far sì che Portage individui tutte le dipendenze che ora possono essere rimosse, usare la funzionalità --depclean di emerge, che verrà discussa in seguito.
Aggiornare il sistema
Per mantenere il sistema in perfetta forma (per non contare l'installazione degli aggiornamenti di sicurezza più recenti) è necessario aggiornare regolarmente il sistema. Poiché Portage controlla solo le ebuild nel repositorio di Gentoo, la prima cosa da fare è aggiornare proprio questo. Quando il repositorio di Gentoo risulta aggiornato, può essere aggiornato il sistema usando emerge --update @world. Nell'esempio successivo, viene usata anche l'opzione --ask, che specifica a Portage di mostrare la lista dei pacchetti da aggiornare e di chiedere conferma:
Portage passerà a cercare versioni più recenti delle applicazioni installate. Tuttavia, verificherà solo le versioni delle applicazioni che sono state esplicitamente installate (le applicazioni elencate in /var/lib/portage/world) - non controllerà a fondo tutte le loro dipendenze. Per aggiornare anche le dipendenze di quei pacchetti, aggiungere l'opzione --deep:
root #emerge --update --deep @worldSe le impostazioni USE del sistema sono state alterate, è raccomandato aggiungere anche --newuse. Così, Portage verificherà se il cambiamento richiede l'installazione di nuovi pacchetti o la ricompilazione di alcuni esistenti:
root #emerge --update --deep --with-bdeps=y --newuse @worldMetapacchetti
Alcuni pacchetti nel repositorio di Gentoo non hanno un effettivo contenuto, ma sono usati per installare una raccolta di pacchetti. Per esempio, il pacchetto kde-apps/kde-meta installerà nel sistema un ambiente KDE completo scaricando vari pacchetti relativi a KDE come dipendenze.
Per rimuovere un pacchetto del genere dal sistema, eseguire emerge --unmerge sul pacchetto non avrà molto effetto in quanto le dipendenze rimarranno nel sistema.
Portage possiede anche la capacità di rimuovere le dipendenze rimaste orfane, ma poiché la disponibilità del software presenta dipendenze dinamiche, per prima cosa è importante aggiornare completamente il sistema, inclusi i nuovi cambiamenti applicati al variare delle opzioni USE. Fatto questo, si esegua emerge --depclean per rimuovere le dipendenze rimaste orfane. Fatto anche questo, potrebbe essere necessario ricompilare le applicazioni che erano dinamicamente collegate ai pacchetti ora rimossi, ma non più richiesti, benché recentemente sia stato aggiunto a Portage del supporto per questo.
Tutto ciò viene gestito con i seguenti tre comandi:
root #emerge --update --deep --newuse @world
root #emerge --depclean
root #revdep-rebuildLicenze
A partire dalla versione 2.1.7 di Portage, è possibile accettare o rifiutare l'installazione del software in base alla sua licenza. Tutti i pacchetti nell'albero contengono una voce LICENSE nelle loro ebuild. Eseguire emerge --search package/category mostrerà la licenza del pacchetto.
{{{1}}}
Normalmente, Portage dà il consenso a tutte le licenze, ad eccezione degli Accordi di Licenza con l'Utente Finale (End User License Agreements - EULAs) che richiedono la lettura e la firma di un accordo di accettazione.
La variabile che controlla le licenze permesse viene chiamata ACCEPT_LICENSE, che può essere impostata nel file /etc/portage/make.conf. Nell'esempio seguente, viene mostrato il suo valore predefinito:
/etc/portage/make.confL'impostazione predefinita di ACCEPT_LICENSEACCEPT_LICENSE="* -@EULA"
Con questa configurazione, i pacchetti che richiedono l'interazione dell'utente durante l'installazione per accettare la propria licenza EULA non saranno installabili. Invece, i pacchetti senza una licenza EULA saranno installabili.
È possibile impostare ACCEPT_LICENSE globalmente su /etc/portage/make.conf, oppure specificarla per ciascun pacchetto tramite file /etc/portage/package.license.
Per esempio, per dare il consenso alla licenza google-chrome per il pacchetto www-client/google-chrome, aggiungere quanto mostrato di seguito nel file /etc/portage/package.license:
/etc/portage/package.licenseAccettare la licenza google-chrome per il pacchetto google-chromewww-client/google-chrome google-chrome
Questo permette l'installazione del pacchetto www-client/google-chrome, ma proibisce l'installazione del pacchetto www-plugins/chrome-binary-plugins, anche se ha la stessa licenza.
Or to allow the often-needed sys-kernel/linux-firmware:
/etc/portage/package.licenseAccepting the licenses for the linux-firmware package# Accepting the license for linux-firmware
sys-kernel/linux-firmware linux-fw-redistributable
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
# Accepting any license that permits redistribution
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
Le licenze sono conservate nella cartella /usr/portage/licenses/, e i gruppi di licenze sono mantenuti nel file /usr/portage/profiles/license_groups. Il primo valore di ciascuna linea in lettere MAIUSCOLE è il nome del gruppo di licenze, ed ogni valore successivo è una licenza individuale.
I gruppi di licenze definiti nella variabile ACCEPT_LICENSE hanno un prefisso che è il simbolo @. Un'impostazione comunemente richiesta è permettere solamente l'installazione di software e documentazione liberi. Per ottenere ciò, rimuovere tutte le licenze attualmente accettate (usando -*) e poi permettere solo le licenze nel gruppo FREE come mostrato di seguito:
/etc/portage/make.confAccettare solamente software e documentazione liberiACCEPT_LICENSE="-* @FREE"
Note that this setting will also accept non-free software and documentation.
Quando Portage si lamenta
Terminologia
Come affermato in precedenza, Portage è estremamente potente e supporta molte caratteristiche di cui sono privi altri strumenti di gestione del software. Per comprenderle, spiegheremo alcuni aspetti di Portage senza entrare troppo nei dettagli.
Con Portage, possono coesistere diverse versioni di un singolo pacchetto su un sistema. Mentre altre distribuzioni tendono a chiamare i loro pacchetti con il numero di versione (come freetype e freetype2), Portage usa una tecnologia chiamata SLOT (fessura). Un'ebuild dichiara un certo SLOT per la sua versione. Possono coesistere ebuild con diversi SLOT nello stesso sistema. Per esempio, il pacchetto freetype ha ebuild con SLOT="1" e SLOT="2".
Ci sono anche pacchetti che forniscono la stessa funzionalità ma che sono implementati in modo diverso. Per esempio, metalogd, sysklogd, e syslog-ng sono tutti logger (registratori di eventi) di sistema. Le applicazioni che si basano sulla disponibilità di un "logger di sistema" non possono dipendere, per esempio, da metalogd, in quando gli altri logger di sistema sono anch'essi una valida scelta. Portage permette di usare logger virtuali: ogni logger di sistema viene elencato come una dipendenza "esclusiva" del servizio di logging (registrazione eventi) nel pacchetto virtuale logger dalla categoria virtuale, così che le applicazioni possano dipendere dal pacchetto virtual/logger. Una volta installato, il pacchetto rappresenterà il primo pacchetto di logging menzionato in esso, a meno che non sia stato già installato un pacchetto di logging (in tal caso quello virtuale risulta soddisfatto).
Il software nel repositorio di Gentoo può risiedere in rami diversi (branch). Normalmente il sistema accetta solo pacchetti che Gentoo reputa stabili. La maggior parte del software nuovo, una volta caricato, viene aggiunto al ramo di prova (testing), per far capire che serve testarlo più a lungo prima di poterlo segnalare come stabile. Benché le ebuild per quei software siano nel repositorio di Gentoo, Portage non le aggiornerà finché non saranno poste nel ramo stabile (stable).
Alcuni software sono disponibili solo per poche architetture. Magari il software non funziona su altre architetture, oppure ha bisogno di più prove, oppure lo sviluppatore che ha aggiunto il software al repositorio di Gentoo non è in grado di verificare se il pacchetto funziona su architetture diverse.
Ogni installazione di Gentoo aderisce anche ad un determinato profilo che contiene, tra le altre informazioni, l'elenco dei pacchetti necessari affinché un sistema funzioni normalmente.
Pacchetti bloccati
[blocks B ] mail-mta/ssmtp (sta bloccando mail-mta/postfix-2.2.2-r1)
- Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
(x11-wm/i3-4.20.1:0/0::gentoo, ebuild scheduled for merge) pulled in by
x11-wm/i3
Le ebuild contengono campi specifici che informano Portage sulle loro dipendenze. Ci sono due dipendenze possibili: dipendenze di costruzione, dichiarate nella variabile DEPEND e dipendenze per l'esecuzione, dichiarate similmente in RDEPEND. Quando una di queste dipendenze segnala esplicitamente un pacchetto effettivo o virtuale come non compatibile, innesca un blocco.
Sebbene le versioni recenti di Portage sono abbastanza intelligenti da eludere i blocchi minori senza l'intervento dell'utente, occasionalmente tali blocchi devono essere risolti manualmente.
Per risolvere un blocco, gli utenti possono scegliere di non installare il pacchetto o di disinstallare prima il pacchetto in conflitto. Nell'esempio dato, si può optare di non installare postfix o di rimuovere prima ssmtp.
Talvolta ci sono anche pacchetti bloccanti con parti specifiche non divisibili, come per esempio <media-video/mplayer-1.0_rc1-r2. In questo caso, l'aggiornamento dello stesso ad una versione più recente potrebbe rimuovere il blocco.
È anche possibile che due pacchetti ancora da installare si blocchino fra loro. In questo raro caso, si tenti di scoprire perché debbano essere installati entrambi. Nella maggior parte dei casi, è sufficiente procedere con uno solo dei pacchetti. Se così non fosse, si segnali cortesemente un errore nel sistema di tracciamento degli errori di Gentoo.
Pacchetti mascherati
!!! tutti gli ebuilds che potrebbero soddisfare "bootsplash" sono stati mascherati.
!!! possibili candidati sono:
- gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword)
- lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword)
- sys-libs/glibc-2.3.4.20040808 (masked by: -* keyword)
- dev-util/cvsd-1.0.2 (masked by: missing keyword)
- games-fps/unreal-tournament-451 (masked by: package.mask)
- sys-libs/glibc-2.3.2-r11 (masked by: profile)
- net-im/skype-2.1.0.81 (masked by: skype-eula license(s))
Quando si tenta di installare un paccheto non disponibile per il sistema, avviene un errore di mascheramento. Gli utenti dovrebbero cercare di installare un'applicazione diversa che sia disponibile per il sistema oppure attendere finché il pacchetto non sarà marcato come disponibile. C'è sempre una ragione se un pacchetto viene mascherato:
| Motivo del mascheramento | Descrizione |
|---|---|
| ~arch keyword | L'applicazione non è stata testata sufficientemente per poter essere messa nel ramo stabile. Attendere qualche giorno o settimana e riprovare. |
| -arch keyword or -* keyword | L'applicazione non funziona sulla propria architettura. Se si ritiene che il pacchetto funzioni, presentare istanza dell'errore sul sito web Bugzilla. |
| missing keyword | L'applicazione non è ancora stata testata sulla propria architettura. Chiedere alla squadra di esportazione dell'architettura di testare il pacchetto oppure lo si testi per loro e si riporti il risultato sul sito web di Bugzilla. |
| package.mask | Il pacchetto si è rivelato corrotto, instabile o anche peggio ed è stato deliberatamente marcato come da non usare. |
| profile | Il pacchetto si è rivelato inadatto per il profilo attuale. L'applicazione potrebbe danneggiare il sistema se viene installato oppure semplicemente non è compatibile con il profilo attualmente in uso. |
| license | La licenza del pacchetto non è compatibile con il valore di ACCEPT_LICENSE. Accetta la sua licenza o imposta il gruppo di licenze corretto configurandolo su /etc/portage/make.conf o su /etc/portage/package.license |
Modifiche necessarie delle opzioni USE
Le seguenti modifiche a USE sono necessarie per procedere:
#required by app-text/happypackage-2.0, required by happypackage (argument)
>=app-text/feelings-1.0.0 test
Il messaggio di errore potrebbe anche essere mostrato come segue, se --autounmask non è impostato:
emerge: non ci sono ebuild costruite con le opzioni USE che soddisfino "app-text/feelings[test]".
!!! È necessario uno dei seguenti pacchetti per completare la propria richiesta:
- app-text/feelings-1.0.0 (Change USE: +test)
(dependency required by "app-text/happypackage-2.0" [ebuild])
(dependency required by "happypackage" [argument])
Tale avvertimento od errore avviene quando si richiede di installare un pacchetto che non solo dipende da un altro pacchetto, ma anche richiede che quel pacchetto sia compilato con una particolare opzione USE (o un insieme di opzioni USE). Nell'esempio mostrato, il pacchetto app-text/feelings deve essere compilato con USE="test", ma questa opzione USE non è impostata nel sistema.
Per risolvere ciò, si aggiunga l'opzione USE richiesta alle opzioni USE globali in /etc/portage/make.conf, oppure impostarla per lo specifico pacchetto in /etc/portage/package.use.
Dipendenze mancanti
emerge: non ci sono ebuild per soddisfare ">=sys-devel/gcc-3.4.2-r4".
!!! Problema con l'ebuild sys-devel/gcc-3.4.2-r2
!!! È possibile che sia un problema DEPEND/*DEPEND.
L'applicazione da installare dipende da un altro pacchetto che non è disponibile per il sistema. Si controlli su Bugzilla se il problema è noto e se così non fosse, lo si segnali. A meno che il sistema non sia configurato per mescolare i rami, questo problema non dovrebbe verificarsi e di conseguenza è un errore.
Nome ebuild ambiguo
[ Risultati per il termine di ricerca : listen ]
[ Applicazioni trovate : 2 ]
* dev-tinyos/listen [ Masked ]
Ultima versione disponibile: 1.1.15
Ultima versione installata: [ Not Installed ]
Dimensione file: 10,032 kB
Homepage: http://www.tinyos.net/
Descrizione: Raw listen for TinyOS
Licenza: BSD
* media-sound/listen [ Masked ]
Ultima versione disponibile: 0.6.3
Ultima versione installata: [ Not Installed ]
Dimensione file: 859 kB
Homepage: http://www.listen-project.org
Descrizione: A Music player and management for GNOME
Licenza: GPL-2
!!! Il nome breve dell'ebuild "listen" è amibiguo. Specificare
!!! uno dei precedenti nomi ebuild completi al suo posto.
L'applicazione selezionata per essere installata ha un nome che corrisponde a più di un pacchetto. Si fornisca anche il nome della categoria per risolvere questo problema. Portage informerà l'utente sulle possibili corrispondenze tra cui scegliere.
Dipendenze circolari
!!! Errore: dipendenze circolari:
ebuild / net-print/cups-1.1.15-r2 dipende dall'ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 dipende dall'ebuild / net-print/cups-1.1.15-r2
Due (o più) pacchetti da installare dipendono l'uno dall'altro e di conseguenza non possono essere installati. Ciò è probabilmente dovuto ad un errore in uno dei pacchetti nel repositorio di Gentoo. Si prega di effettuare nuovamente la sincronizzazione dopo un po' e riprovare di nuovo. Potrebbe anche essere utile controllare Bugzilla per vedere se il problema è noto e se non lo è, segnalarlo.
Acquisizione fallita
!!! Acquisizione (fetch) fallita per sys-libs/ncurses-5.4-r5, sto procedendo...
(...)
!!! Alcuni errori di acquidizione sono stati riscontrati. Si prega di leggere i dettagli soprastanti.
Portage non è riuscito a scaricare i sorgenti per una certa applicazione e continuerà ad installare le altre applicazioni (se possibile). Questo fallimento può dipendere da un mirror che non è stato sincronizzato correttamente oppure perché l'ebuild punta ad una posizione non corretta. Il server in cui risiedono i sorgenti può anche essere spento per qualche ragione.
Ritentare dopo un'ora per vedere se il problema persiste.
Protezione del profilo di sistema
!!! Tentativo di disinstallare uno o più pacchetti del profilo di sistema. 'sys-apps/portage'
!!! Questo potrebbe danneggiare il sistema.
L'utente ha richiesto di rimuovere un pacchetto che è parte dei pacchetti fondamentali del sistema. Esso è elencato nel profilo come necessario, di conseguenza non dovrebbe essere rimosso dal sistema.
Verifica somme di controllo fallita
>>> verifica delle somme di controllo delle ebuild
!!! Verifica del compendio (digest) fallita:
Questo indica che qualcosa è andato storto nel repositorio di Gentoo - spesso è dovuto ad un errore di consegna di una ebuild nel repositorio dell ebuild di Gentoo.
Quando la verifica del compendio (digest) fallisce, non si tenti di ricreare il compendio con le somme di controllo personalmente. Eseguire ebuild foo manifest non risolverà il problema; anzi è probabile che peggiorerà la situazione.
Piuttosto, attendere un'ora o due affinché il repositorio si sistemi. È probabile che l'errore sia stato già segnalato, ma la soluzione può impiegare del tempo prima che arrivi nei mirror rsync. Controllare Bugzilla e vedere se qualcuno ha già segnalato il problema o chiedere su #gentoo (webchat) (IRC). Se il problema non è noto, proseguire e presentare istanza del problema per l'ebuild corrotta.
Una volta che l'errore è stato corretto, ri-sincronizzare il repositorio delle ebuild di Gentoo per ottenere il compendio con le somme di controllo revisionato.
Prestare attenzione a non sincronizzare il repositorio delle ebuild di Gentoo più di una volta al giorno. Come riportato nella politica ufficiale della condotta su Internet (netiquette) di Gentoo (come anche quando si esegue emerge --sync), agli utenti che effettuano la sincronizzazione troppo spesso verrà temporaneamente preclusa la possibilità di farlo per un certo periodo di tempo. Gli utenti che abuseranno di ciò ripetutamente potranno essere bloccati. A meno che non sia assolutamente necessario, spesso è meglio aspettare un periodo di circa 24 ore prima di effettuare nuovamente la sincronizzazione, così che quest'ultima non sovraccarichi i mirror rsync di Gentoo.