Il requisito di eguale visibilità

Un ebuild non deve dipendere da un pacchetto che ha un livello di keyword più basso di se stesso. Per esempio, se foo-1.2 dipende da bar-1.2 e quest'ultimo è marcato ~x86, foo-1.2 non può essere marcato stabile per x86 a meno che non divenga stabile anche bar-1.2.

Tutte le possibili dipendenze devono soddisfare la regola suddetta. Da notare comunque che certi flag USE possono essere disabilitati forzatamente su base per-profile da richiedere al gruppo che si occupa della data architettura.

Mascheramenti hard

Il file package.mask può essere utilizzato per mascherare in modo hard sia singoli ebuild che gruppi. Questo dovrebbe essere utilizzato durante la fase di test degli ebuild o rilasci beta di software e anche per pacchetti che presentano seri problemi di compatibilità. Pacchetti che non sono mascherati hard non devono essere dipendenti da pacchetti che invece lo sono.

La sola possibilità per un utente di avere un messaggio di errore del tipo Possibly DEPEND problem è per una modifica manuale al livello di visibilità di un pacchetto (ad esempio attraverso /etc/portage/) che ha fallito una dipendenza. Non si dovrebbero mai fare modifiche che potrebbero causare tali errori.

'Allucchettare' nuovi pacchetti

Non si parta dal presupposto che un pacchetto funzioni su tutte le architetture. Né che un ebuild proposto da un utente abbia KEYWORDS corrette dato che potrebbe essere partito da un ebuild preesistente. Non si presuma neanche che un codice, perché scritto in Perl / Python / Java, funzioni su altre architetture (c'è almeno un caso di uno script vim che funziona solo su x86).

Keyword negli aggiornamenti

Quando si propone un aggiornamento, porre la keyword da arch ad ~arch lasciando qualsiasi altra keyword ~arch intatta. Questo deve essere fatto anche se si pensa di aver introdotto solo una piccola correzione, ci sono stati alcuni esempi di pacchetti considerati stabili che non hanno funzionato per questo motivo.

Qualche volta si può aver bisogno di rimuovere una keyword a causa di una dipendenza non risolta. Per questo occorre inviare un rapporto al gruppo che si occupa dell'architettura che riguarda la keyword rimossa.

Questo naturalmente si applica anche alle modifiche effettuate sulle semplici revisioni.

Passare da ~arch ad arch

Il passaggio di un pacchetto da ~arch a arch è fatto solo dal team che si occupa dell'architettura in oggetto. Se si ha accesso ad hardware non x86 ma non si fa parte del team relativo, si possono fare modifiche individuali e, se ne è a conoscenza, il team che si occupa dell'architettura sarà felice di dare una mano. Da notare che anche x86 non fa eccezione e per far considerare stabile un pacchetto occorre passare per il team che si occupa di tale architettura.

Per divenire stabile un pacchetto deve seguire queste linee guida:

• deve essere stato in ~arch per un certo periodo di tempo, di solito una trentina di giorni (è chiaramente una indicazione di massima). Per pacchetti critici ci si aspetta una durata maggiore mentre per piccoli pacchetti con modifiche minori tra le versioni è appropriato un breve periodo
• il pacchetto non deve avere dipendenze non-arch
• non deve avere gravi bug insoluti
• se è una libreria, non dovrebbe corrompere i pacchetti da lei dipendenti
• il team che si occupa dell'architettura ne deve convenire la stabilità

Per fissare bug che riguardano la sicurezza, i tempi ragionevoli si possono allungare.

Rimuovere versioni di pacchetti

Quando si rimuove un ebuild, ci si assicuri di non rimuoverne la versione più recente se esiste in qualche livello di keyword in ogni profilo. Lo scopo è: non forzare il downgrade. (Eccezione: occasionalmente si può voler forzare un downgrade, se, per esempio, una nuova versione di un pacchetto ha seri problemi, questa è la miglior soluzione. Ma resta un caso raro).

Non deve rompere nessuna dipendenza esistente.