Repository & pinning: differenze tra le versioni

Esistono diverse distribuzioni ([[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|distribuzioni]] 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 che non siano esperti riguardo il funzionamento di [[APT]] di non ricorrervi se non strettamente necessario.

{{Warningbox|Installare pacchetti provenienti da distribuzioni e/o fonti 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]].}}

{{Box|Importante|Il pinning è uno strumento per regolare la priorità in base al numero di versione dei pacchetti, e non alla fonte di provenienza. Non è possibile discriminare tra pacchetti aventi la stessa versione e provenienti da più repository, ovvero ad essere installato sarà quello proveniente dal repository elencato per primo nel file <code>sources.list</code>.}}

* priorità '''500''' alle versioni che non appartengono alla distribuzione 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 distribuzione obiettivo, posto che sia definita.

* si desidera installare il pacchetto "vattelapesca" appartenente alla propria distribuzione (si supponga testing);

* tutti i pacchetti presenti in repoA appartengono alla distribuzione installata, in repoB e repoC sono contenuti pacchetti appartenenti ad un'altra distribuzione (ad esempio unstable e stable rispettivamente);

* non esiste un file <code>preferences</code> o comunque non è stata specificata una priorità per nessuna delle tre distribuzioni considerate;

* non è stato dichiarato il parametro ''Default Release'' in un eventuale file <code>apt.conf</code>, ovvero non è stata definita una distribuzione obiettivo.

* Pin compreso tra '''1 e 99''', il candidato sarà installato solo se sono verificate entrambe queste condizioni: non esistono candidati appartenenti ad altre distribuzioni, 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 distribuzioni e se la versione eventualmente già installata non è superiore.

* Pin compreso tra '''500 e 989''', il candidato sarà installato solo se non esistono candidati appartenenti alla distribuzione obiettivo e se la versione eventualmente già installata non è superiore a quella del candidato. Si noti che il semplice fatto di aver installato una certa distribuzione, per esempio testing, non significa aver definito la distribuzione obiettivo, che può essere solo definita manualmente dall'utente (il come sarà spiegato nella discussione del file <code>apt.conf</code>).

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

che equivale alla dichiarazione in riga di comando dell'opzione '''-t distribuzione_voluta''' sia in [[Apt-get | Apt-Get]] che [[Aptitude]]. Tale dichiarazione attribuisce priorità 990 a tutti i pacchetti appartenenti alla distribuzione specificata.

* Tale priorità si applica alla distribuzione 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.

* 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 distribuzione_taldeitali</code> sorpassa qualunque distribuzione 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/distribuzione_taldeitali</code> non cambiano la ''target release'', ma si limitano a dire di prelevare lo specifico pacchetto dalla distribuzione indicata invece che da quella predefinita. Questo implica che le dipendenze continueranno ad essere risolte in base alla distribuzione obiettivo eventualmente specificata in <code>apt.conf</code> e/o in base al file preferences e/o in accordo all'algoritmo predefinito.

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

Pin: release a=distribuzione_voluta

* Qualora si sia definita una distribuzione obiettivo in <code>apt.conf</code> allora quasiasi dichiarazione in <code>preferences</code> riguardante tutti i pacchetti di una certa distribuzione sarà ignorata, ad esempio definire

Nel primo esempio si è definito il pinning per il pacchetto di nome "vlc", richiedendo che le versioni appartenenti alla distribuzione 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.

{{Suggerimento|Specificare nel file <code>sources.list</code> sempre per primi il o i repository principali della distribuzione obiettivo.}}

La distribuzione 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.

Sia testing l'unica distribuzione 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.

# Poiché entrambe le fonti, ''principale'' e ''deb-multimedia'', appartengono alla distribuzione 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 distribuzione 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 distribuzione 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.

# L'utilizzo dell'opzione '''-t''' in questo caso è inutile, visto che si lavora per ipotesi con una sola distribuzione.

# L'installazione di tutti i pacchetti provenienti da distribuzioni differenti da testing è completamente impedita, anche nel caso si aggiungessero repository relativi ad altre distribuzioni (a meno ovviamente di non aggiungere opportuni record in <code>preferences</code>).