Repository & pinning: differenze tra le versioni

che equivale alla dichiarazione in riga di comando dell'opzione '''<code>-t release_voluta</code>''' in [[apt-get]], [[apt]] e [[aptitude]]. Tale dichiarazione attribuisce priorità 990 a tutti i pacchetti appartenenti alla [[release]] specificata.

* Tale priorità si applica alla release e non alla fonte, quindi ad ottenere la suddetta priorità non saranno solo i pacchetti appartenenti al repository principale (o ai due repository principali), ma anche quelli provenienti da altre fonti se il gestore di tale repository usa lo stesso valore per i parametri [[suite]] e [[codename]] di quelli principali, ad esempio stable e ''jessie''.

* Per quanto riguarda tutti i pacchetti della target release questa dichiarazione ha la precedenza su qualsiasi altra generica priorità definita nel file ''preferences'', ad eccezione di quei pacchetti per ciascuno dei quali sia stata definita una specifica priorità.

* Comandi del tipo <code>apt-get install pacchetto/release_taldeitali</code> non cambiano la ''target release'', ma si limitano a dire di prelevare lo specifico pacchetto dalla release indicata invece che da quella predefinita. Questo implica che le dipendenze continueranno ad essere risolte in base alla release obiettivo eventualmente specificata in <code>apt.conf</code> e/o in base al file <code>preferences</code> e/o in accordo all'algoritmo predefinito.

* Le dichiarazioni di parametri da riga di comando hanno sempre la precedenza su quelli definiti in un file di configurazione, che di conseguenza verranno ignorati, quindi usare un comando del tipo <code>apt-get install pacchetto -t release_taldeitali</code> disabilita durante l'esecuzione qualunque release obiettivo (<code>Default-Release</code>) dichiarata nel file <code>apt.conf</code>. Perciò avere un pinning a 990 in preferences non è necessariamente equivalente a impostare una <code>Default-Release</code>.

* Definire una release obiettivo in <code>apt.conf</code> è quasi equivalente a dichiarare in <code>preferences</code> (si veda la prossima sezione) quanto segue:

:senonché, qualora si sia definita una <code>Default-Release</code> in <code>apt.conf</code>, qualsiasi dichiarazione in <code>preferences</code> riguardante tutti i pacchetti (<code>Package: *</code>) di quella stessa release sarà ignorata. Per esempio sarebbe del tutto inutile definire:

* Ricapitolando <code>-t release_voluta</code> ignora e ha gli stessi effetti di una <code>Default-Release</code>, che a sua volta ignora ogni generica (<code>Package: *</code>) impostazione di pinning relativa alla stessa release.

{{Box|File multipli|L'utente può, invece di creare un unico file di nome ''apt.conf'', creare più file di nome arbitrario in ''/etc/apt/apt.conf.d/'' (si veda il manuale)}}

Questo è il file dove è possibile definire tutte le priorità che si vogliono, fermo restando quanto detto nella sezione dedicata ad <code>apt.conf</code>. La sintassi generale è la seguente:

Un paio di esempi del tutto arbitrari:

Nel primo esempio si è definito il pinning per il pacchetto di nome "vlc", richiedendo che le versioni appartenenti alla release testing abbiano priorità 991. Nel secondo invece sfruttando una semplicissima espressione regolare si impone che tutti i pacchetti il cui nome inizia per "virtualbox4" e appartenenti al repository la cui origine è definita come "Oracle Corporation" abbiano priorità 780.

= Esempi =

Non serve il pinning se si usano i repository ufficiali di una sola release di Debian, ed è '''sconsigliato''' anche impostare una <code>Default-Release</code> in <code>apt.conf</code>.

Si ricorda nuovamente che in una release pura non serve il pinning nemmeno per i [[backports]], perché i pacchetti contenuti non sono mai installati automaticamente senza specificare una release obiettivo (opzione <code>-t</code>/<code>--target-releae</code> con [[apt-get]]), salvo presenti soltanto lì, ma una volta che i pacchetti sono installati dai backports verranno aggiornati automaticamente.

Inoltre anche nel caso che si utilizzino soltanto i repository [[sid]] ed [[experimental]] non sarebbe necessario alcun pinning, dato che gli experimental di default hanno una ''Pin-Priority'' di 1, che impedisce sia l'installazione sia l'aggiornamento automatico dei pacchetti contenuti.

== Stable con backports obbligati ==

Si supponga di voler usare tutti i pacchetti della stable, con l'eccezione di quelli relativi a libreoffice che si vuole siano prelevati esclusivamente dai [[backports]].

Questo esempio '''non''' è consigliato, ma intende soltanto mostrare alcune delle problematiche nella configurazione del pinning, quando si applica solo a una selezione ristretta di pacchetti.

{{Warningbox | Si noti infatti che mentre è possibile impedire l'installazione dei pacchetti dalla stable quando presenti anche nei backports, non è possibile garantirne l'installazione automatica dei pacchetti dai backports. Questo perché, per soddisfare tutte le possibili dipendenze dei pacchetti installati, l'unico modo sarebbe assegnare un pinning di almeno 500 a tutti i pacchetti provenienti dai backports.

Si ricorda però che i backports non sono sottoposti agli stessi controlli dei repository principali della stable, per cui è sconsigliato l'uso indiscriminato di tutti i pacchetti contenuti, in particolare per macchine di produzione. È invece consigliabile utilizzarli soltanto per i pacchetti di cui si ha una reale necessità.}}

=== sources.list ===

deb http://ftp.it.debian.org/debian/ jessie main

deb-src http://ftp.it.debian.org/debian/ jessie main

 

deb-src http://security.debian.org/ jessie/updates main

deb http://ftp.it.debian.org/debian/ jessie-updates main

deb-src http://ftp.it.debian.org/debian/ jessie-updates main

deb http://ftp.it.debian.org/debian/ jessie-backports main

Quello mostrato è solo un esempio con: i due repository principali di [[Jessie]], quello normale e di sicurezza; gli aggiornamenti raccomandati, che non sono strettamente necessari; e i backports.

Di default si ricordi che tutti i repository hanno una priorità di 500, a eccezione di '''jessie-backports''' che ne hanno una di 100.

Non serve modificarlo, né crearlo se non esiste, ed è anzi consigliabile non impostare la <code>Default-Release</code>. Si noti infatti che il suo utilizzo per '''jessie''' non avrebbe effetto sugli aggiornamenti raccomandati ('''jessie-updates'''), che verrebbero quindi disabilitati come i backports.

=== preferences ===

Pin-Priority: 990

Per come è definito <code>preferences</code> l'installazione della versione di libreoffice da repository non backports è impossibile, una volta che i pacchetti entrano in tale [[repository]], anche usando l'opzione <code>-t</code> da riga di comando.

Si noti che solo il pacchetto <code>libreoffice</code> e tutte le dipendenze inizianti con quello stesso prefisso possono essere installate automaticamente dai backports, per cui l'installazione o l'aggiornamento non sono garantiti in presenza di altre dipendenze da soddisfare dallo stesso ramo senza l'uso di:

Questo è il motivo per cui si sconsiglia l'uso del pinning per i backports, visto che basta utilizzare direttamente questo comando, senza modificare le impostazioni del sistema.

Questo file è valido per tutti gli esempi di questa sezione, mentre gli altri dipendono dalla configurazione del pinning desiderata.

Pin: release a=testing

Pin: release a=testing

Adesso è possibile installare il pacchetto "nomepacchetto" da testing con:

# apt-get install nomepacchetto

oppure in caso di dipendenze con:

# apt-get -t testing install nomepacchetto

{{Box | Aptitude | È possibile anche installare il pacchetto tramite [[aptitude]]:

# aptitude install nomepaccheto

 

Si presti però attenzione alle soluzioni proposte, prima di accettarle. Questo metodo '''non''' è consigliato, ma è presentato per completezza per chiarire come in alcuni casi è possibile l'installazione di un pacchetto senza specificare manualmente l'opzione <code>-t</code>.}}

 

Si noti anche che non si avranno aggiornamenti automatici per i pacchetti che vengono installati con questo metodo, a meno che riguardino soltanto quel singolo pacchetto e nessun altro. In caso contrario bisogna rieseguire il precedente comando, avvalersi di <code>aptitude</code> per risolvere i conflitti, oppure impostare il pinning con la configurazione trattata in seguito.

Pin: release a=testing

Dove ''jessie-backports'' è il nome della [[suite]] (e il [[codename]], che sono uguali per i [[backports]]) dei repository backports di [[Jessie]]. È consigliabile specificare la nuova priorità a prescindere dalla loro presenza, altrimenti se attivati saranno sempre nascosti da testing, avendo di default una priorità di 100 e contenendo versioni non più aggiornate.

* testing deve avere una priorità inferiore a quella scelta per ''jessie-backports'';

* testing e ''jessie-backports'' devono avere una priorità almeno pari a 100, per consentire gli aggiornamenti automatici una volta che un pacchetto è installato da tali repository.

# apt-get -t testing install nomepacchetto

per installare nuovi pacchetti da testing, che saranno poi aggiornati in automatico. Si noti però che perfino in questo caso gli aggiornamenti potrebbero comunque richiedere l'uso dell'opzione <code>-t</code>, se nuove dipendenze fossero aggiunte in testing, oppure il meccanismo di risoluzione automatica dei conflitti di [[aptitude]].

Questa configurazione assegna al repository principale e a quello di sicurezza di testing un pinning di 990. Di conseguenza sid resta a 500 ed experimental a 1.

### Debian testing

### Debian testing - sicurezza

### repository NON ufficiali - multimedia

Senza altre impostazioni, tutti i repository avrebbero una priorità di 500, e pertanto di default verrebbero sempre installati quelli solitamente più aggiornati di deb-multimedia, ogni volta che è possibile. Questo comportamento non è affatto desiderabile, e anzi può compromettere la stabilità del sistema.

Non è necessaria nessuna modifica. Sarebbe inoltre del tutto inutile impostare una <code>Default-Release</code>, poiché sia i repository ufficiali sia quelli di deb-multimedia sono considerati testing.

Con questa impostazione il repository deb-multimedia si comporta in maniera analoga ai repository backports ufficiali, consentendo l'installazione automatica dei soli pacchetti non presenti in altri repository e anche l'aggiornamento automatico di tutti i pacchetti precedentemente installati dallo stesso.

* Poiché entrambe le fonti, ''principale'' e ''deb-multimedia'', appartengono alla release testing in teoria questo caso non sarebbe gestibile tramite pinning, tuttavia sotto l'ipotesi di voler installare da deb-multimedia solo i pacchetti non presenti nella fonte principale il problema è risolvibile. Evitando di definire in <code>apt.conf</code> una release obiettivo e definendo in <code>preferences</code> prima il record relativo a deb-multimedia si ottiene di riuscire ad assegnare la priorità desiderata, nonostante il fatto che il secondo record si applichi in teoria anche a deb-multimedia. Si noti che stanti così le cose dovrebbe essere in realtà possibile attribuire pin superiori, fino a 499, a deb-multimedia, senza che per questo i suoi candidati ottengano la precedenza su quelli del repository principale.

: [[Utente:HAL 9000|HAL 9000]] 21:37, 10 mag 2015 (CEST)