Repository & pinning: differenze tra le versioni

Vai alla navigazione Vai alla ricerca

Repository & pinning (visualizza wikitesto)

Versione delle 20:40, 22 apr 2016

7 568 byte aggiunti ,  22 apr 2016
m
→‎Testing con unstable ed experimental: avviso link
m (uniformazione)
(44 versioni intermedie di 4 utenti non mostrate)
Riga 3: Riga 3:
|successivo=Repository ufficiali
|successivo=Repository ufficiali
}}
}}
{{Template:Articoli ezine|titolo=Repository e Pinning|intro=Una rapida panoramica su uno dei temi più importanti in Debian: il funzionamento e la configurazione dei repository, ed il pinning ovvero la possibilità di attingere dai repository dei diversi rami, cercando di mantenere il sistema più stabile possibile.<br/>
|abstract=Dopo aver installato una Debian nasce il bisogno di aggiungere nuovi programmi e allo stesso tempo tenerla costantemente aggiornata. Per questo scopo Debian dispone di un tool potentissimo: apt (Advanced Packaging Tool), con numerosi strumenti sia da riga di comando (la shell), come dpkg, apt-get, aptitude, dselect, wajig, sia per mezzo di interfacce grafiche come synaptic, aptitude, adept, gjig ed altri. Per comprendere appieno tutto il meccanismo delle installazioni e degli aggiornamenti bisogna conoscere com'è strutturata una Debian. Questo articolo vuole essere un'introduzione alla comprensione della struttura per la gestione dei 20.000 ed oltre pacchetti che Debian offre. Per approfondimenti consultare le ricche pagine di documentazione che accompagnano Debian come debian-reference-it, debian-faq-it, etc.<br/>
|1=[http://e-zine.debianizzati.org/web-zine/numero_2/?page=12 Repository e Pinning]}}
{{Versioni compatibili}}
{{Versioni compatibili}}
__TOC__
{{E-zine
|num=2
|articoli=[http://e-zine.debianizzati.org/web-zine/numero_2/?page=12 Repository & Pinning]
}}
= Introduzione =
= Introduzione =
Esistono diverse [[release]] di Debian, e si rimanda per maggiori dettagli a [[La struttura della Distribuzione]]. E in una configurazione normale, e consigliata, di Debian non è necessario configurare il [[pinning]] per nessuna.
Esistono diverse [[release]] di Debian, e si rimanda per maggiori dettagli a [[La struttura della Distribuzione]]. E in una configurazione normale, e consigliata, di Debian non è necessario configurare il [[pinning]] per nessuna.


Il pinning entra in gioco qualora si desiderino delle regole personalizzate per determinati pacchetti o [[repository]], o se si vogliono utilizzare i repository di più release di Debian contemporaneamente. Inizialmente era necessario anche per utilizzare altri repository, quali i ''backports'' o gli ''experimental'', ma attualmente la necessità di configurarlo è venuta meno in molte situazioni, e pertanto si raccomanda agli utenti non esperti nell'uso di [[APT]] di non ricorrervi a meno che sia strettamente necessario.
Il pinning entra in gioco qualora si desiderino delle regole personalizzate per determinati pacchetti o [[repository]], o se si vogliono utilizzare i repository di più release di Debian contemporaneamente. Inizialmente era necessario anche per utilizzare altri repository, quali i [[backports]] o gli [[experimental]], ma attualmente la necessità di configurarlo è venuta meno in molte situazioni, e pertanto si raccomanda agli utenti non esperti nell'uso di [[APT]] di non ricorrervi a meno che sia strettamente necessario.


{{Warningbox|Installare pacchetti provenienti da release differenti è sempre e comunque fonte di rischi, ed è sconsigliato. Questa guida presuppone la comprensione dei concetti esposti nella guida [[I repository ed il loro utilizzo]], nonché la conoscenza di [[apt-get]].}}
{{Warningbox|Installare pacchetti provenienti da release differenti è sempre e comunque fonte di rischi, ed è sconsigliato. Questa guida presuppone la comprensione dei concetti esposti nella guida [[I repository ed il loro utilizzo]], nonché la conoscenza di [[apt-get]].}}
Riga 19: Riga 20:
= Priorità come punteggio =
= Priorità come punteggio =
La priorità viene gestita attraverso l'assegnazione di un punteggio ai vari pacchetti, sia installati che ancora da installare. Valgono le seguenti regole:
La priorità viene gestita attraverso l'assegnazione di un punteggio ai vari pacchetti, sia installati che ancora da installare. Valgono le seguenti regole:
* priorità '''1''', caso particolare e poco comune. È quella di default per ''experimental'' ('''NotAutomatic: yes''' nel file ''Release'' del repository). Si veda il manuale per maggiori informazioni.
* priorità '''1''', caso particolare e poco comune. È quella di default per experimental ('''NotAutomatic: yes''' nel file ''Release'' del repository). Si veda il manuale per maggiori informazioni.
* priorità '''100''' alla versione dei pacchetti già installati e quella dei backports ufficiali ('''NotAutomatic: yes''' e '''ButAutomaticUpgrades: yes''' nel file ''Release'' del repository).
* priorità '''100''' alla versione dei pacchetti già installati e quella dei backports ufficiali ('''NotAutomatic: yes''' e '''ButAutomaticUpgrades: yes''' nel file ''Release'' del repository).
* priorità '''500''' alle versioni che non appartengono alla release obiettivo, dove con quest'ultimo termine si deve intendere "Default Release", "Target Release". Di default non è impostata una "Default Release", e quindi ogni repository a parte ''backports'' ed ''experimental'' ha una priorità di 500.
* priorità '''500''' alle versioni che non appartengono alla release obiettivo, dove con quest'ultimo termine si deve intendere "Default Release", "Target Release". Di default non è impostata una "Default Release", e quindi ogni repository a parte backports ed experimental  ha una priorità di 500.
* priorità '''990''' alle versioni che appartengono alla release obiettivo, posto che sia definita.
* priorità '''990''' alle versioni che appartengono alla release obiettivo, posto che sia definita.


Piccolo esempio teorico. Si supponga quanto segue:
Piccolo esempio teorico. Si supponga quanto segue:
* si desidera installare il pacchetto "vattelapesca" appartenente alla propria [[release]] (si supponga testing);
* si desidera installare il pacchetto "vattelapesca" appartenente alla propria [[release]] (si supponga [[testing]]);
* il suddetto pacchetto è presente in tre fonti: repoA, repoB, repoC; tutte correttamente specificante nel file <code>source.list</code>;
* il suddetto pacchetto è presente in tre fonti: repoA, repoB, repoC; tutte correttamente specificante nel file <code>sources.list</code>;
* tutti i pacchetti presenti in repoA appartengono alla release installata, in repoB e repoC sono contenuti pacchetti appartenenti ad un'altra release (ad esempio unstable e stable rispettivamente);
* tutti i pacchetti presenti in repoA appartengono alla release installata, in repoB e repoC sono contenuti pacchetti appartenenti ad un'altra release (ad esempio [[unstable]]/[[Sid]] e [[stable]] rispettivamente);
* la versione di "vattelapesca" in repoA è la 1.4, in repoB la 2.0 e in in repoC la 1.1;
* la versione di "vattelapesca" in repoA è la 1.4, in repoB la 2.0 e in in repoC la 1.1;
* nel sistema è installata la versione 1.3 di "vattelapesca";
* nel sistema è installata la versione 1.3 di "vattelapesca";
Riga 37: Riga 38:
Il problema evidentemente non può che esplodere quando si tenta di aggiornare tutti i pacchetti di sistema.
Il problema evidentemente non può che esplodere quando si tenta di aggiornare tutti i pacchetti di sistema.


La soluzione è quella di assegnare manualmente un punteggio ai vari pacchetti, singolarmente o raggruppandoli. Prima però è necessario capire il significato dei vari punteggi (''Pin-Priority''). Nel seguito si indicherà col termine "candidato" il pacchetto o gruppo di pacchetti proveniente dalla generica fonte dichiarata nel file <code>sources.list</code>.
= Pin-priority =
Nel precedente esempio si sarebbe ottenuto l'aggiornamento di '''tutti''' i pacchetti alla loro versione in unstable (se si stava utilizzando una testing), ossia un risultato ben lontano dal voler aggiornare '''un solo pacchetto''' con la versione presente in unstable.<br/>
La soluzione è quella di assegnare manualmente un punteggio ai vari pacchetti, singolarmente o raggruppandoli. Prima però è necessario capire il significato dei vari punteggi (''Pin-Priority'').<br/>
Nel seguito si indicherà col termine "candidato" il pacchetto o gruppo di pacchetti proveniente dalla generica fonte dichiarata nel file <code>sources.list</code>.


* Pin '''minore di 0''' (negativo), l’installazione automatica del candidato è impedita a priori.
* Pin '''minore di 0''' (negativo), l'installazione automatica del candidato è impedita a priori.
* Pin compreso tra '''1 e 99''', il candidato sarà installato solo se sono verificate entrambe queste condizioni: non esistono candidati appartenenti ad altre release, e nel sistema non è già installata una versione (anche inferiore) del candidato.
* Pin compreso tra '''1 e 99''', il candidato sarà installato solo se sono verificate entrambe queste condizioni: non esistono candidati appartenenti ad altre release, e nel sistema non è già installata una versione (anche inferiore) del candidato.
* Pin compreso tra '''100 e 499''', il candidato sarà installato solo se non esistono candidati appartenenti ad altre release e se la versione eventualmente già installata non è superiore.
* Pin compreso tra '''100 e 499''', il candidato sarà installato solo se non esistono candidati appartenenti ad altre release e se la versione eventualmente già installata non è superiore.
Riga 50: Riga 54:
# Non esistono altri candidati dello stesso pacchetto provenienti dalle altre fonti, infatti APT assegnerebbe a loro automaticamente una priorità di 500 (500 > 44).
# Non esistono altri candidati dello stesso pacchetto provenienti dalle altre fonti, infatti APT assegnerebbe a loro automaticamente una priorità di 500 (500 > 44).
# Nessun candidato di "vattelapesca" è mai stato installato, infatti alla versione installata di "vattelapesca" sarebbe assegnata una priorità di 100 (100 > 44), a prescindere dalla sua versione, ovvero anche quando questa fosse inferiore a quella del nuovo candidato di stable disponibile.
# Nessun candidato di "vattelapesca" è mai stato installato, infatti alla versione installata di "vattelapesca" sarebbe assegnata una priorità di 100 (100 > 44), a prescindere dalla sua versione, ovvero anche quando questa fosse inferiore a quella del nuovo candidato di stable disponibile.
{{Box|Nota|* APT può derogare alle regole generali sopra esposte in casi particolari per soddisfare le varie dipendenze dei pacchetti.}}


== Priorità in caso di aggiornamento ==
== Priorità in caso di aggiornamento ==
Riga 58: Riga 60:
* i pacchetti installati hanno priorità 100, e quindi un pacchetto può essere aggiornato automaticamente se esiste un repository con una priorità di almeno 100 che contenga una versione più recente di quella installata.
* i pacchetti installati hanno priorità 100, e quindi un pacchetto può essere aggiornato automaticamente se esiste un repository con una priorità di almeno 100 che contenga una versione più recente di quella installata.


Per esempio la stable di default ha priorità 500 (ma quanto scritto varrebbe anche con una priorità fino a 990), mentre i backports ne hanno una di 100. Ciò significa che non si può installare (automaticamente) una versione di un pacchetto dai backports che si trovi in entrambi i repository.<br/>
Per esempio la [[stable]] di default ha priorità 500 (ma quanto scritto varrebbe anche con una priorità fino a 990), mentre i [[backports]] ne hanno una di 100. Ciò significa che non si può installare (automaticamente) una versione di un pacchetto dai backports che si trovi in entrambi i repository.<br/>
Ma se si è già installato un pacchetto dai backports, impostando manualmente la target release, quel pacchetto verrà aggiornato automaticamente quando saranno disponibili nuovi aggiornamenti, perché:
Ma se si è già installato un pacchetto dai backports, impostando manualmente la target release, quel pacchetto verrà aggiornato automaticamente quando saranno disponibili nuovi aggiornamenti, perché:
* la priorità della stable non è sufficiente al [[downgrade]], dato che servirebbe una priorità di almeno 1000, e pertanto il repository è ignorato;
* la priorità della stable non è sufficiente al [[downgrade]], dato che servirebbe una priorità di almeno 1000, e pertanto il repository è ignorato;
Riga 64: Riga 66:


Si noti che con una priorità superiore a 990 per la stable sarebbe impossibile installare i backports, anche manualmente. Tale priorità potrebbe essere assegnata dopo la loro installazione, ma sempre senza superare 1000 per evitare il [[downgrade]].
Si noti che con una priorità superiore a 990 per la stable sarebbe impossibile installare i backports, anche manualmente. Tale priorità potrebbe essere assegnata dopo la loro installazione, ma sempre senza superare 1000 per evitare il [[downgrade]].
== Priorità a singoli pacchetti ==
Se anziché attribuire un valore di ''Pin-Priority'' a tutti i pacchetti di un dato repository, lo si assegna soltanto a un insieme specifico di pacchetti, le loro dipendenze '''non''' ne saranno soggette.
Ciò significa che una particolare versione di un pacchetto può essere installata o aggiornata, senza specificare manualmente la release obiettivo, unicamente se la priorità di quel dato pacchetto e di tutte le sue dipendenze lo consentono. In un certo senso quindi la priorità di un dato pacchetto si può considerare pari al valore minimo fra la ''Pin-Priority'' del pacchetto stesso e l'insieme delle ''Pin-Priority'' di tutte le dipendenze ancora da soddisfare.
{{Box|Nota|Alcuni programmi della suite APT possono derogare alle regole generali per soddisfare le varie dipendenze dei pacchetti. Per esempio è il caso di [[aptitude]], che è in grado di proporre risoluzioni automatiche dei conflitti, consentendo anche di ignorare il pinning.}}


= /etc/apt/apt.conf =
= /etc/apt/apt.conf =
Questo file insieme ad altri permette di definire le opzioni di APT e relativi strumenti senza bisogno di digitarli sempre da riga di comando. Si vedano le guide dedicate ad [[Apt-get | Apt-Get]] e [[Aptitude]] per alcuni brevi esempi contenenti alcui dei parametri più comuni.
Questo file insieme ad altri permette di definire le opzioni di APT e relativi strumenti senza bisogno di digitarli sempre da riga di comando. Si vedano le guide dedicate ad [[apt-get]] e [[Aptitude]] per dei brevi esempi contenenti alcuni dei parametri più comuni.<br/>
Per quanto riguarda il pinning l'unico parametro strettamente di rilievo è:
Per quanto riguarda il pinning l'unico parametro strettamente di rilievo è:


<pre>APT::Default-Release "release_voluta";</pre>
<pre>APT::Default-Release "release_voluta";</pre>


che equivale alla dichiarazione in riga di comando dell'opzione '''-t release_voluta''' sia in [[Apt-get | Apt-Get]] che [[Aptitude]]. Tale dichiarazione attribuisce priorità 990 a tutti i pacchetti appartenenti alla [[release]] specificata.
che equivale alla dichiarazione in riga di comando dell'opzione '''<code>-t release_voluta</code>''' (anche nella forma <code>--target-release release_voluta</code>) in [[apt-get]], [[apt]] e [[aptitude]].
 
Tale dichiarazione:
* attribuisce priorità 990 a tutti i pacchetti appartenenti alla [[release]] specificata;
* ignora tutte le impostazioni di pinning in <code>/etc/apt/preferences</code> riguardanti la stessa release e relative a tutti i pacchetti (anziché a un singolo pacchetto o a un gruppo di pacchetti).
 
Pertanto si raccomanda di '''non''' impostare una <code>Default-Release</code> se si vuole utilizzare anche il file <code>/etc/apt/preferences</code>, per non creare conflitti tra le due configurazioni.


{{Warningbox|
{{Warningbox|
* 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 ''wheezy''. Per esempio ''backports'' non comporta problemi poiché i precedenti due parametri valgono ''nome_suite-backports'' e ''nome_codename-backports'', viceversa quello di ''deb-multimedia'' usa gli stessi identici valori di quelli principali.
* 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 ''{{Codename|stable}}''.
* 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à.
* Questa direttiva influenza la priorità del repository principale di una release, nonché di quella relativa alla sua sicurezza, per esempio:
* Questa direttiva influenza la priorità del repository principale di una release, nonché di quella relativa alla sua sicurezza, ad esempio
** <code>deb <nowiki>http://ftp.it.debian.org/debian/</nowiki> {{Codename|stable}} main</code>
** <code>deb http://ftp.it.debian.org/debian/ wheezy main</code>
** <code>deb <nowiki>http://security.debian.org/</nowiki> {{Codename|stable}}/updates main</code>
** <code>deb http://security.debian.org/ wheezy/updates main</code>
}}
}}


Si noti inoltre che:
Si noti inoltre che:
* Le dichiarazioni di parametri da riga di comando hanno sempre la precedenza su quelli definiti in un file di configurazione, quindi usare un comando del tipo <code>apt-get install pacchetto -t release_taldeitali</code> sorpassa qualunque release obiettivo (''Default-Release'') dichiarata nel file <code>apt.conf</code>. Perciò avere un pinning a 990 in preferences non è necessariamente equivalente a impostare una ''Default-Release''.
* 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.
* 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 preferences 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 <code>preferences</code> non è necessariamente equivalente a impostare una <code>Default-Release</code>, anche in assenza di conflitti tra i due file di configurazione.
* Definire una release obiettivo in <code>apt.conf</code> è equivalente a dichiarare in <code>preferences</code> (si veda la prossima sezione) quanto segue
<pre>
Package: *
Pin: release a=release_voluta
Pin-Priority: 990
</pre>
* Qualora si sia definita una release obiettivo in <code>apt.conf</code> allora quasiasi dichiarazione in <code>preferences</code> riguardante tutti i pacchetti di una certa release sarà ignorata, ad esempio definire
<pre>
Package: *
Pin: release a=testing
Pin-Priority: 1000
</pre>
: è del tutto inutile se poi si usa l'opzione '''-t testing'''. Non è invece inutile una dichiarazione del seguente tipo:
<pre>
Package: specifico pacchetto o espressione regolare
Pin: release a=testing
Pin-Priority: 1000
</pre>


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


= /etc/apt/preferences =
= /etc/apt/preferences =
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:
Questo è il file dove è possibile definire tutte le priorità che si vogliono, fermo restando quanto detto nella sezione dedicata ad <code>apt.conf</code> di utilizzare soltanto uno dei file per il pinning. La sintassi generale è la seguente:
<pre>
<pre>
Package: nome pacchetto o espressione regolare
Package: nome pacchetto o espressione regolare
Riga 112: Riga 108:
Pin-Priority: numero
Pin-Priority: numero
</pre>
</pre>
Un paio di esempi del tutto arbitrari:
 
<pre>
Un po' di esempi del tutto arbitrari:
Package: vlc
 
Pin: release a=testing
Package: vlc
Pin-Priority: 991
Pin: release a=testing
   
Pin-Priority: 991
Package: virtualbox4*
 
Pin: Release o=Oracle Corporation
Package: vlc
Pin-Priority: 780
Pin: release n={{Codename|testing}}
</pre>
  Pin-Priority: 991
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.
 
Package: virtualbox4*
Pin: Release o=Oracle Corporation
Pin-Priority: 780
 
Il primo e il secondo esempio sono equivalenti, il primo fa riferimento alla [[suite]] (detta anche '''''a'''rchive'') mentre il secondo al [[codename]] ('''''n'''ome in codice''). In entrambi si è definito il pinning per il pacchetto di nome "vlc", richiedendo che le versioni appartenenti alla release testing, attualmente [[{{Codename|Testing}}]], abbiano priorità 991. Attenzione però che quando {{Codename|Testing}} diverrà la nuova [[stable]], il primo si applicherà alla nuova testing mentre il secondo continuerà a far riferimento a {{Codename|Testing}}. Solitamente è consigliabile il secondo (con ''codename''), se si utilizza una stable e si vogliono prelevare pacchetti da testing, mentre il primo (con ''suite'') se si utilizza una testing e si vuole restare sempre con quella. La scelta dovrebbe inoltre riflettere quella adottata per tutti i repository in <code>/etc/apt/sources.list</code>, tenendo presente anche che i [[backports]] contengono sempre il ''codename''.
 
Nel terzo esempio invece, sfruttando un semplicissimo pattern, 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.


Il pinning può essere orientato ai campi "Suite", "Origin", "Label" e "Codename" del file "Release" di un certo repository (si veda [[i repository ed il loro utilizzo]]), nonché all'indirizzo del repository stesso. Si noti che per archivi personali e/o non ufficiali può non essere presente (purtroppo) un file "Release".
Il pinning può essere orientato ai campi "Suite", "Origin", "Label" e "Codename" del file "Release" di un certo repository (si veda [[i repository ed il loro utilizzo]]), nonché all'indirizzo del repository stesso. Si noti che per archivi personali e/o non ufficiali può non essere presente (purtroppo) un file "Release".
Riga 149: Riga 152:
Per maggiori informazioni si consulti la guida [[Fare il downgrade di uno o più pacchetti]].
Per maggiori informazioni si consulti la guida [[Fare il downgrade di uno o più pacchetti]].


=== Retrocedere l'intero sistema ===
{{Warningbox | Si noti che cercare di retrocedere l'intero sistema, impostando un pinning superiore a 1000 per tutti i pacchetti di una precedente [[release]], '''È UNA FOLLIA!'''
Nella maggior parte dei casi (o forse sempre) questa '''È UNA FOLLIA''', tuttavia per motivazioni didattiche si mostra come fare. In primis è necessario eliminare, se presente, dal file <code>apt.conf</code> il parametro ''default-release'', dopo di che aggiungere al file <code>preferences</code> un record come il seguente (sostituire a "stable" la versione desiderata, ad esempio "testing" se si vuole retrocedere da "unstable").
 
<pre>
Non è un'operazione minimamente supportata né testata, in quanto è opposta a quella che avviene con l'aggiornamento tramite APT e ha grandi probabilità di rendere l'intero sistema inusabile. Si raccomanda caldamente invece di effettuare una nuova installazione della [[release]] desiderata.}}
Package: *
Pin: release a=stable
Pin-Priority: 1001
</pre>
A questo punto dovrebbe essere sufficiente digitare da terminale:
<pre># apt-get dist-upgrade</pre>


= Esempi =
= Esempi senza bisogno di pinning =
{{Box|Nota|Per il significato dei vari parametri dichiarati in <code>apt.conf</code>, nonché per la relativa sintassi, si vedano le guide dedicate ad [[apt-get]], ecc. Si ricordi inoltre che non sempre la definizione di tale file è necessaria ai fini del pinning.}}


== Release pura ==
== Release pura ==
Non serve il pinning se si usano i repository ufficiali di una sola release di Debian, ma può essere prudente definire un file <code>apt.conf</code> se si dovessero aggiungere altri repository in seguito e ci si dimenticasse di definire correttamente un pinning.
Non serve il pinning se si usano i [[repository ufficiali]] o quelli [[repository speciali|speciali]] di una sola release di Debian, ed è '''sconsigliato''' anche impostare una <code>Default-Release</code> in <code>apt.conf</code>.


Ciò avrebbe effetto sul repository principale e su quello della sicurezza. Ma non sugli eventuali ''updates'' o ''proposed-updates'', che non sarebbero più aggiornati automaticamente, salvo che per i pacchetti già installati da quei repository. Per riabilitare gli aggiornamenti automatici è necessario impostare un pinning a 990, pari a quello della ''Default-Release''.
Infatti ciò avrebbe effetto sul repository principale e su quello della sicurezza, ma non sugli eventuali ''updates'' o ''proposed-updates'', che non sarebbero più aggiornati automaticamente, salvo che per i pacchetti già installati da quei repository. Per riabilitare gli aggiornamenti automatici sarebbe necessario impostare un pinning a 990, pari a quello della <code>Default-Release</code>.


In una release pura i pacchetti dei ''backports'' continuano a restare disabilitati per la loro prima installazione, salvo presenti soltanto lì o li si scelga come target release, ma i pacchetti installati dai ''backports'' vengono aggiornati automaticamente senza bisogno di pinning. Il che corrisponde al loro comportamento di default anche in assenza di una ''Default-Release''.
== Stable con backports ==
Non è necessario alcun pinning nemmeno aggiungendo i [[backports]] ai repository della [[stable]] (attualmente [[{{Codename|Stable}}]]), in quanto di default sono disattivati, a eccezione dei pacchetti presenti soltanto lì, e consentono solo l'aggiornamento automatico dei pacchetti installati manualmente dai backports.


== Stable con backports obbligati ==
Per installare un pacchetto dai backports la prima volta, basta utilizzare [[apt]] (o equivalentemente [[apt-get]]):
Si supponga di voler usare tutti i pacchetti della stable, con l'eccezione di quelli relativi a libreoffice.
# apt -t {{Codename|stable}}-backports install nomepacchetto


=== sources.list ===
Per esempio per installare <code>libreoffice</code>:
# apt -t {{Codename|stable}}-backports install libreoffice
 
Dopo di che sarà aggiornato automaticamente assieme agli altri pacchetti di {{Codename|Stable}} con:
<pre>
<pre>
deb http://ftp.it.debian.org/debian/ stable main
# apt update
deb-src http://ftp.it.debian.org/debian/ stable main
# apt upgrade
</pre>
Si noti invece che potrebbe essere necessario un <code>dist-upgrade</code> se si utilizza [[apt-get]].
 
=== Backports automatici ===
{{Warningbox | Questo esempio '''non''' è consigliato, ma intende soltanto mostrare alcune delle problematiche nella configurazione del pinning.
 
Si ricorda infatti 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à, come visto nella sezione precedente.}}


deb http://security.debian.org/ stable/updates main
Si supponga di voler usare tutti i pacchetti della [[stable]], con l'eccezione di quelli relativi a <code>libreoffice</code> che si vuole siano prelevati esclusivamente dai [[backports]]. È bene chiarire subito che '''non esiste alcun modo di garantire ciò''' tramite il pinning, poiché le [[dipendenze]] di un pacchetto non sono influenzate dalla sua ''Pin-Priority''. Quello che si può fare è trovare una soluzione di compromesso, che è quasi sempre più svantaggiosa di quella proposta nella sezione precedente, ossia non utilizzando alcun pinning.
deb-src http://security.debian.org/ stable/updates main


deb http://ftp.it.debian.org/debian/ wheezy-backports main
Infatti è possibile soltanto impedire l'installazione dei pacchetti dalla stable quando presenti anche nei backports. Questo perché, per soddisfare tutte le possibili dipendenze dei pacchetti installati, l'unico modo sarebbe assegnare una ''Pin-Priority'' di almeno 500 a tutti i pacchetti provenienti dai backports, che di default ne hanno una di 100.
deb-src http://ftp.it.debian.org/debian/ wheezy-backports main
</pre>


=== apt.conf ===
Le principali alternative, presentate a solo scopo didattico:
<pre>
* nessuna <code>Default-Release</code> in <code>apt.conf</code> e file <code>/etc/apt/preferences</code> come segue
APT
Package: libreoffice
{
Pin: release n={{Codename|stable}}-backports
        Default-Release "stable";
Pin-Priority: 500
        Cache-Limit 36000000;
* nessuna <code>Default-Release</code> in <code>apt.conf</code> e file <code>/etc/apt/preferences</code> come segue
        Get
Package: libreoffice*
        {
Pin: release n={{Codename|stable}}-backports
                AutomaticRemove "true";
Pin-Priority: 500
                Fix-Broken "true";
* nessuna impostazione in <code>/etc/apt/preferences</code> e file <code>/etc/apt/apt.conf</code> come segue
                Purge "true";
APT::Default-Release "{{Codename|stable}}-backports";
                Show-Upgraded "true";
        }
}
Aptitude
{
        Autoclean-After-Update "true";
        Auto-Fix-Broken "true";
        Purge-Unused "true";
}
</pre>


=== preferences ===
La prima possibilità restituisce errore quando si cerca di installare il pacchetto, costringendo a ricorrere all'opzione <code>-t</code> oppure lasciando ad [[aptitude]] il compito di risolvere i conflitti. In modo analogo può restituire errore durante un aggiornamento, se richiede anche l'aggiornamento delle sue [[dipendenze]], costringendo a ripetere il comando di installazione con <code>-t</code>.
<br/>
<pre>
Package: libreoffice*
Pin: release n=wheezy-backports
Pin-Priority: 992
</pre>


=== Osservazioni ===
La seconda possibilità riesce più spesso, in quanto quasi tutte le dipendenze cominciano con la stringa ''libreoffice'' e sono quindi catturate dal pattern ''libreoffice'''*''''', tuttavia nemmeno ciò garantisce il funzionamento automatico in ogni circostanza, per via di possibili altre dipendenze con altri nomi. E anche se aggiungessimo pure tali pacchetti, si aumenterebbe soltanto la frequenza di successo, senza però mai avere una garanzia nella totalità dei casi, visto che nuove dipendenze potrebbero essere aggiunte in successivi aggiornamenti.
Per come è definito <code>preferences</code> l'installazione della versione di libreoffice da repository non ''backports'' è impossibile, anche usando l'opzione <code>-t</code> da riga di comando.


== Testing con unstable==
La terza alternativa è l'unica che funziona sempre in automatico, ma si applica indiscriminatamente a tutti i pacchetti contenuti nei ''backports'', che è proprio quello che si voleva evitare per una [[stable]].
La release principale sia testing, quella secondaria unstable. Lo scopo è far sì che '''non''' vengano recuperati in automatico da unstable tutti i pacchetti già disponibili in testing.


=== sources.list ===
{{Box | Backports obbligatori | Specificando una priorità di 990 anziché 500 nel file <code>/etc/apt/preferences</code>, come visto in questa sezione, l'installazione di <code>libreoffice</code> dai repository non backports fallirebbe anche utilizzando l'opzione <code>-t {{Codename|stable}}</code>, rendendo l'installazione da ''{{Codename|stable}}-backports'' l'unica possibile (anche se non garantita senza l'uso dell'opzione <code>-t {{Codename|stable}}-backports</code>).
<pre>
deb http://ftp.it.debian.org/debian/ testing main
deb-src http://ftp.it.debian.org/debian/ testing main


deb http://security.debian.org/ testing/updates main
Si noti invece che l'uso dei backports non è obbligatorio specificando la <code>Default-Release</code> a ''{{Codename|stable}}-backports'', per le ragioni già esposte nella sezione su <code>apt.conf</code> di questa guida, anche se lo sarebbero gli aggiornamenti (in assenza di conflitti con le dipendenze).}}
deb-src http://security.debian.org/ testing/updates main


deb http://ftp.it.debian.org/debian unstable main
== Unstable/Sid ed experimental ==
deb-src http://ftp.it.debian.org/debian unstable main
Se si utilizzino soltanto i repository [[sid]] ed [[experimental]] non è 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.
</pre>


=== apt.conf ===
Per installare o aggiornare un pacchetto da experimental, basta eseguire:
<pre>
<pre># apt-get -t experimental install nomepacchetto</pre>
APT
{
        Default-Release "testing";
        Cache-Limit 36000000;
        Get
        {
                AutomaticRemove "true";
                Fix-Broken "true";
                Purge "true";
                Show-Upgraded "true";
        }
}
Aptitude
{
        Autoclean-After-Update "true";
        Auto-Fix-Broken "true";
        Purge-Unused "true";
}
</pre>


=== preferences ===
= Esempi con pinning =
Non è necessario configurare alcun pinning, ma è sufficiente l'uso di <code>Default-Release</code> nel file <code>apt.conf</code>.


=== Osservazioni ===
== Stable con testing ==
# Usando le azioni ''install'' e ''upgrade'' senza specificare l'opzione '''-t unstable''' si installano/aggiornano pacchetti prelevando le versioni da testing, a meno che un pacchetto sia presente solo in unstable, nel qual caso sarà prelevato da lì. Le dipendenze saranno risolte se possibile usando testing, altrimenti usando unstable.
{{Warningbox | Senza pinning ci si troverebbe con una testing effettuando gli aggiornamenti del sistema.
# Digitando <code>apt-get -t unstable install vattelapesca</code> si installerà la versione "vattelapesca" appartenente ad unstable, così come le sue dipendenze. Si noti che dopo l'avvenuta installazione, successivi aggiornamenti tramite comandi del tipo <code>apt-get upgrade</code> o <code>apt-get dist-upgrade</code> continueranno a installare la versione più recente, anche prelevandola automaticamente da ''unstable'', almeno finché la versione in testing non diverrà equivalente a quella in unstable.
# Una volta che la versione in testing divenisse uguale a quella presente in unstable, successive versioni presenti soltanto in unstable non sarebbero aggiornate automaticamente, ma servirebbe specificare nuovamente l'opzione '''-t'''/'''--target-release'''.


== Testing con deb-multimedia ==
Ma anche con il pinning c'è il pericolo che a ogni aggiornamento aumenti la possibilità che nuove dipendenze da testing siano necessarie, rendendo la provenienza dei pacchetti della propria distribuzione sempre più mista, senza i benefici di nessuna delle due e quindi in una situazione meno desiderabile di un passaggio diretto a testing.}}
Sia testing l'unica release d'interesse, nonché quella obiettivo. Si supponga di voler usare anche la fonte ''www.deb-multimedia.org'', ma con l'unico scopo di installare solo quei pacchetti che non sono presenti nel repository principale.


{{Box|Nota|Questo esempio non permette di retrocedere automaticamente pacchetti già installati da deb-multimedia.}}
Per prima cosa si devono aggiungere i [[Repository ufficiali|repository di testing]]. Di seguito sono esaminate diverse possibilità di pinning, in base alla configurazione desiderata.


=== sources.list ===
=== sources.list ===
Abilitiamo anche le sezioni ''contrib'' e ''non-free'':
deb <nowiki>http://ftp.it.debian.org/debian/</nowiki> {{Codename|stable}} main
<pre>
deb-src <nowiki>http://ftp.it.debian.org/debian/</nowiki> {{Codename|stable}} main
### Debian testing
deb http://ftp.it.debian.org/debian/ testing main contrib non-free
# Aggiornamenti di sicurezza
deb-src http://ftp.it.debian.org/debian/ testing main contrib non-free
deb <nowiki>http://security.debian.org/</nowiki> {{Codename|stable}}/updates main
deb-src <nowiki>http://security.debian.org/</nowiki> {{Codename|stable}}/updates main
# Aggiornamenti raccomandati
deb <nowiki>http://ftp.it.debian.org/debian/</nowiki> {{Codename|stable}}-updates main
deb-src <nowiki>http://ftp.it.debian.org/debian/</nowiki> {{Codename|stable}}-updates main
# Backports
deb <nowiki>http://ftp.it.debian.org/debian/</nowiki> {{Codename|stable}}-backports main
deb-src <nowiki>http://ftp.it.debian.org/debian/</nowiki> {{Codename|stable}}-backports main
# Testing
deb <nowiki>http://ftp.it.debian.org/debian/</nowiki> {{Codename|testing}} main
deb-src <nowiki>http://ftp.it.debian.org/debian/</nowiki> {{Codename|testing}} main
# Aggiornamenti di sicurezza di testing
deb <nowiki>http://security.debian.org/</nowiki> {{Codename|testing}}/updates main
deb-src <nowiki>http://security.debian.org/</nowiki> {{Codename|testing}}/updates main


### Debian testing - sicurezza
Quello mostrato è solo un esempio con i due repository principali di [[{{Codename|Stable}}]], quello normale e di sicurezza, gli aggiornamenti raccomandati e i backports, che non sono strettamente necessari per questo esempio (ma è sempre preferibile cercare prima in questi repository che in testing), e i due repository di [[{{Codename|Testing}}]] ([[testing]]).
deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ testing/updates main contrib non-free


### repository NON ufficiali - multimedia
Questo file è valido per tutti gli esempi di questa sezione, mentre gli altri dipendono dalla configurazione del pinning desiderata. Si noti in particolare la scelta del [[codename]] (''{{Codename|testing}}'') al posto della [[suite]] (''testing''), che è la configurazione consigliata in presenza di una [[stable]] e verrà quindi mantenuta anche per il pinning.
deb http://www.deb-multimedia.org testing main non-free
deb-src http://www.deb-multimedia.org testing main non-free
</pre>


=== apt.conf ===
=== apt.conf ===
Non si utilizza in questo caso, per non creare conflitti con il file <code>/etc/apt/preferences</code>. Assicurarsi perciò che <code>/etc/apt/apt.conf</code> non contenga una riga su <code>Default-Release</code>, che se presente va cancellata.
=== Pinning per un singolo pacchetto ===
Creare il file <code>/etc/apt/preferences</code> con questo contenuto:
Package: nomepacchetto
Pin: release n={{Codename|testing}}
Pin-Priority: 990
Package: *
Pin: release n={{Codename|testing}}
Pin-Priority: -1


Questa configurazione si consiglia soltanto per pacchetti che non richiedono l'installazione di altri da testing.
Si può controllarne il funzionamento con:
<pre>
<pre>
APT
$ apt-get --simulate install nomepacchetto
{
        Cache-Limit 36000000;
        Get
        {
                AutomaticRemove "true";
                Fix-Broken "true";
                Purge "true";
                Show-Upgraded "true";
        }
}
Aptitude
{
        Autoclean-After-Update "true";
        Auto-Fix-Broken "true";
        Purge-Unused "true";
}
</pre>
</pre>
(e si può usare la forma abbreviata <code>-s</code> al posto di <code>--simulate</code>)


=== preferences ===
In assenza di problemi, sarà possibile installare il pacchetto "nomepacchetto" da testing semplicemente con:
 
<br/>
<pre>
<pre>
Package: *
# apt-get install nomepacchetto
Pin: Release o=Unofficial Multimedia Packages
</pre>
Pin-Priority: 101


Package: *
In presenza di dipendenze, o si aggiungono al file <code>preferences</code> se non sono molte, oppure si consiglia la configurazione presentata nella sezione successiva.
Pin: Release a=Testing
Pin-Priority: 990


Package: *
{{Warningbox | Infatti mentre sarebbe possibile forzarne l'installazione con:
Pin: release o=Debian
# apt-get -t {{Codename|testing}} install nomepacchetto
Pin-Priority: -10
c'è da considerare che l'uso dell'opzione <code>-t</code> renderebbe il pinning per "nomepacchetto" superfluo; e inoltre la configurazione attuale impedirebbe gli aggiornamenti automatici delle dipendenze appena installate, costringendo a ripetere il comando precedente in caso di conflitti oppure ad avvelersi di [[aptitude]] per risolverli (prestando '''molta attenzione''' alle soluzioni proposte).}}
</pre>


=== Osservazioni ===
=== Pinning per tutti i pacchetti di testing e backports ===
Questa possibilità consente gli aggiornamenti automatici dei pacchetti installati manualmente da testing, permettendone l'installazione anche in assenza di altre versioni disponibili. È sufficiente scrivere il file <code>/etc/apt/preferences</code> come segue:
Package: *
Pin: release a={{Codename|stable}}-backports
Pin-Priority: 300
Package: *
Pin: release n={{Codename|testing}}
Pin-Priority: 200
Dove ''{{Codename|stable}}-backports'' è il nome della [[suite]] (e il [[codename]], che sono uguali per i [[backports]]) dei repository backports di [[{{Codename|Stable}}]]. È consigliabile specificare la nuova priorità a prescindere dalla loro presenza, altrimenti se attivati saranno sempre nascosti da [[{{Codename|Testing}}]], avendo di default una priorità di 100 e contenendo versioni non più aggiornate.


# 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 989, a deb-multimedia, senza che per questo i suoi candidati ottengano la precedenza su quelli del repository principale. Qualora invece si desiderasse dare la precedenza ai pacchetti di deb-multimedia sarebbe sufficiente definire la release obiettivo in <code>apt.conf</code> risultando perfino inutile definire un file <code>preferences</code>, visto che come già detto di norma i candidati di deb-multimedia hanno numero di versione maggiore di queli del repository principale.
Si noti che i valori scelti non sono gli unici possibili. L'importante è che siano soddisfatte le seguenti condizioni:
# L'utilizzo dell'opzione '''-t''' in questo caso è inutile, visto che si lavora per ipotesi con una sola release.
* ''{{Codename|stable}}-backports'' deve avere una priorità inferiore a quella di default (500), utilizzata per ''{{Codename|stable}}'' e ''{{Codename|stable}}-updates'';
# L'installazione di tutti i pacchetti provenienti da release differenti da testing è completamente impedita, anche nel caso si aggiungessero repository relativi ad altre release (a meno ovviamente di non aggiungere opportuni record in <code>preferences</code>).
* ''{{Codename|testing}}'' deve avere una priorità inferiore a quella scelta per ''{{Codename|stable}}-backports'';
# La definizione di un file <code>apt.conf</code> in questo esempio non è necessaria ai fini del pinning.
* ''{{Codename|testing}}'' e ''{{Codename|stable}}-backports'' devono avere una priorità almeno pari a 100, per consentire gli aggiornamenti automatici una volta che un pacchetto è installato da tali repository.


== Mix di varie release ==
Ora basterà:
In questo how-to mostrerò come utilizzare pacchetti Debian provenienti da Testing, Unstable, Experimental e deb-multimedia (audio/video) ma le istruzioni sono facilmente riportabili anche ad altre situazioni (unstable + experimental, stable + testing, stable + unstable, stable + testing + unstable, ecc.).
# apt-get -t {{Codename|testing}} install nomepacchetto
per installare nuovi pacchetti da {{Codename|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> oppure il meccanismo di risoluzione dei conflitti di [[aptitude]], se nuove dipendenze fossero aggiunte nello stesso ramo.


=== Impostare i repository ===
== Testing con unstable ed experimental ==
Assicuriamoci di essere l'utente root e procediamo.
<!--
  NOTA: *NON* cambiare il nome della sezione "Testing con unstable ed experimental", perché è utilizzata da altre guide.
-->
La release principale sia [[testing]], quella secondaria [[Sid]]/[[unstable]] e si utilizzino anche i repository [[experimental]].  


Per prima cosa editiamo il file <code>/etc/apt/sources.list</code> ed inseriamo gli archivi dei pacchetti Debian che utilizzeremo, per esempio (con ''contrib'' e ''non-free'' abilitati):
=== sources.list ===
<pre>
<pre>
### Debian Ufficiale -- Testing
deb http://ftp.it.debian.org/debian/ testing main
deb http://ftp.it.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.it.debian.org/debian/ testing main
deb-src http://ftp.it.debian.org/debian/ testing main contrib non-free
 
# Aggiornamenti di sicurezza
deb http://security.debian.org/ testing/updates main
deb-src http://security.debian.org/ testing/updates main
 
# Unstable
deb http://ftp.it.debian.org/debian/ sid main
deb-src http://ftp.it.debian.org/debian/ sid main
 
# Experimental
deb http://ftp.it.debian.org/debian/ experimental main
deb-src http://ftp.it.debian.org/debian/ experimental main
</pre>


### Debian Ufficiale -- Testing Sicurezza
Si noti che i repository sono indicati per [[suite]] anziché per [[codename]], in questo modo la propria release rimarrà sempre [[testing]] senza mai divenire la nuova [[stable]].
deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ testing/updates main contrib non-free


### Debian Ufficiale -- Sid
Di default tutti hanno priorità 500, a eccezione di experimental che ha una priorità di 1. È il motivo per cui, se si utilizzassero soltanto sid ed experimental non sarebbe necessario alcun pinning, avendo già priorità differente.
deb http://ftp.it.debian.org/debian/ unstable main contrib non-free
deb-src http://ftp.it.debian.org/debian/ unstable main contrib non-free


###  Debian Ufficiale -- Experimental
La configurazione inoltre sarebbe equivalente anche se non si utilizzasse il repository experimental, ma soltanto testing e sid, e sarebbe sufficiente rimuovere experimental dal file <code>/etc/apt/sources.list</code> .
deb http://ftp.it.debian.org/debian/ experimental main contrib non-free
deb-src http://ftp.it.debian.org/debian/ experimental main contrib non-free


### deb-multimedia -- Audio/Video -- Marillat
=== apt.conf ===
deb http://www.deb-multimedia.org testing main non-free
<pre>
deb-src http://www.deb-multimedia.org testing main non-free
APT::Default-Release "testing";
</pre>
</pre>


=== Configurare apt ===
Come nel <code>sources.list</code> la release è indicata per ''suite''.
A questo punto dobbiamo preparare due file normalmente non presenti sulla nostra debianbox: si tratta dei file <code>/etc/apt/preferences</code> e <code>/etc/apt/apt.conf</code>.
Questi due file istruiranno APT su come gestire le dipendenze dei pacchetti, informandolo su come comportarsi in caso di conflitti e altri problemi.


==== Il file <code>apt.conf</code> ====
Questa configurazione assegna al repository principale e a quello di sicurezza di testing una ''Pin-Priority'' di 990. Di conseguenza sid resta a 500 ed experimental a 1.
Ora creiamo il file <code>/etc/apt/apt-conf</code>


<pre># touch /etc/apt/apt.conf</pre>
=== preferences ===
Non è necessario configurare alcun pinning, perché è sufficiente l'uso di <code>Default-Release</code> nel file <code>apt.conf</code>.


ed editiamolo inserendo quanto segue:
=== Osservazioni ===
# Usando le azioni ''install'' e ''upgrade'' senza specificare l'opzione '''<code>-t sid</code>''' si installano/aggiornano pacchetti prelevando le versioni da testing, a meno che un pacchetto sia presente solo in sid, nel qual caso sarà prelevato da lì. Le dipendenze saranno risolte se possibile usando testing, altrimenti usando sid.
# Digitando <code>apt-get -t sid install vattelapesca</code> si installerà la versione "vattelapesca" appartenente ad sid, così come le sue dipendenze. Si noti che dopo l'avvenuta installazione, successivi aggiornamenti tramite comandi del tipo <code>apt-get upgrade</code> o <code>apt-get dist-upgrade</code> continueranno a installare la versione più recente, anche prelevandola automaticamente da sid, almeno finché la versione in testing non diverrà equivalente.
# Una volta che la versione in testing divenisse uguale a quella presente in sid, successive versioni presenti soltanto in sid non sarebbero aggiornate automaticamente, ma servirebbe specificare nuovamente l'opzione <code>-t</code>/<code>--target-release</code>.
# I pacchetti contenuti in experimental sono installabili unicamente se non sono già installati e se non sono presenti in nessun altro repository. Altrimenti è necessario ricorrere all'opzione <code>-t</code>.
# Tutto quello che è installato da experimental non sarà mai aggiornato in automatico. Questo comportamento è del tutto voluto, perché sarebbe troppo pericoloso aggiornare senza supervisione ciò che proviene da questo repository, essendo quello meno testato e potenzialmente con maggiori bug. Per effettuare l'aggiornamento è sufficiente ripetere il comando di installazione: <br/><code># apt-get -t experimental install nomepacchetto</code>
 
== Testing con pacchetti non-free e repository deb-multimedia ==
Sia testing l'unica release d'interesse. Si supponga di voler usare anche la fonte ''www.deb-multimedia.org'', ma con l'unico scopo di installare solo quei pacchetti che non sono presenti nel repository principale.
 
{{Box|Nota|Questo esempio non permette di retrocedere automaticamente pacchetti già installati da deb-multimedia.}}
 
=== sources.list ===
Abilitiamo anche le sezioni ''contrib'' e ''non-free'':
<pre>
<pre>
APT::Cache-Limit 15000000;
# Debian testing
Apt::Get::Purge;
deb http://ftp.it.debian.org/debian/ testing main contrib non-free
APT::Clean-Installed;
 
APT::Get::Fix-Broken;
# Debian testing - sicurezza
APT::Get::Fix-Missing;
deb http://security.debian.org/ testing/updates main contrib non-free
APT::Get::Show-Upgraded "true";
 
# repository NON ufficiali - multimedia
deb http://www.deb-multimedia.org testing main non-free
</pre>
</pre>


'''Nota''': la sintassi usata in quest'esempio, pur essendo differente da quella dei precedenti, è del tutto equivalente. Anche in questo caso è bene sottolineare che la definizione di un file <code>apt.conf</code> non è necessaria ai fini del pinning.
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.


==== Il file <code>preferences</code> ====
=== apt.conf ===
Creiamo il file <code>/etc/apt/preferences</code>:
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.
<pre># touch /etc/apt/preferences</pre>


ed editiamolo col nostro editor di fiducia e inseriamo queste direttive:
=== preferences ===
<pre>
<pre>
Package: *
Package: *
Pin: release a=unstable
Pin: Release o=Unofficial Multimedia Packages
Pin-Priority: 400
Pin-Priority: 100
</pre>
</pre>


Si noti che ''experimental'' ha un ''Pin-Priority'' implicito pari a 1, e che quelli non specificati hanno un valore di 500, pertanto non è necessario impostare regole per ''deb-multimedia'' e ''testing'', che sarebbero equivalenti, ed ''experimental''.
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.


Facciamo l'update del database dei pacchetti:
=== Osservazioni ===
<pre># apt-get update</pre>
* 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.
 
* L'utilizzo dell'opzione <code>-t</code>/<code>--target-release</code> in questo caso è inutile, visto che si lavora per ipotesi con una sola release.
D'ora in avanti avremo due possibilità per installare un nuovo pacchetto: il metodo che usiamo di solito e cioè:
<pre># apt-get install nome_pacchetto</pre>
che utilizzerà pacchetti proveniente dalla versione impostata come '''Default-Release''' in '''apt.conf''', oppure il comando
<pre># apt-get install -t versione_di_debian nome_pacchetto</pre>
che provvederà a installare il pacchetto da noi richiesto per la versione specificata (versione_debian), risolvendo automaticamente le dipendenze.


= Comandi utili =
= Comandi utili =
È possibile visualizzare l'elenco delle priorità relative a tutti i repository e pacchetti dichiarati col seguente comando:
È possibile visualizzare l'elenco delle priorità relative a tutti i repository e pacchetti dichiarati con [[apt-cache]]:
<pre># apt-cache policy</pre>
<pre>$ apt-cache policy</pre>


Se si volesse visualizzare solo la priorità per un singolo singolo pacchetto, ad esempio nano, si può digitare:
Se si volesse visualizzare solo la priorità per un singolo singolo pacchetto, ad esempio nano, si può digitare:
<pre># apt-cache policy nano</pre>
<pre>$ apt-cache policy nano</pre>
 
Si consiglia anche l'installazione di [[apt-show-versions]], per poter controllare velocemente da quali repository provengono i pacchetti installati sul sistema.


Si veda anche la guida di [[apt-get]].
E per controllare se è stata impostata una <code>Default-Release</code> basta:
<pre>$ apt-config dump | grep -i default-release</pre>
che visualizza la riga relativa solo se presente.


= Approfondimenti =
= Approfondimenti =
=== Manpages ===
=== Manpages ===
<code>man apt.conf</code><br/>
<code>man apt.conf</code><br/>
<code>man apt_preferences</code>
<code>man apt_preferences</code>


{{Autori
{{Autori
|Autore = [[User:Keltik|Keltik]]
|Autore = [[User:Xtow|Xtow]]
|Estesa_da =
|Estesa_da =
: [[Utente:Nest|Nest]] (versione preunione)
: [[Utente:Ferdybassi|Ferdybassi]] (versione preunione)
: [[Utente:Wtf|Wtf]]
: [[Utente:Wtf|Wtf]]
: [[Utente:xtow|xtow]] (versione preunione)
: [[Utente:HAL 9000|HAL 9000]]
: [[Utente:HAL 9000|HAL 9000]]
|Verificata_da =
|Verificata_da =
: [[Utente:TheNoise|TheNoise]] (versione preunione)
: [[Utente:Wtf|Wtf]]
: [[Utente:Wtf|Wtf]]
: [[Utente:HAL 9000|HAL 9000]] 11:03, 31 ago 2014 (CEST)
: [[Utente:HAL 9000|HAL 9000]] 13:01, 11 mag 2015 (CEST)
|Numero_revisori = 3
|Numero_revisori = 2
}}
}}


[[Categoria:Apt]]
[[Categoria:Apt]][[Categoria:E-zine]][[Categoria:Repository ufficiali]]
[[Categoria:E-zine]]
[[Categoria:Repository ufficiali]]
HAL 9000
3 581

contributi

Estratto da "https://guide.debianizzati.org/index.php/Speciale:DiffMobile/36306...40997"

Menu di navigazione