Repository & pinning: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
 
(118 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/>
{{Versioni compatibili}}
|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/>
__TOC__
|1=[http://e-zine.debianizzati.org/web-zine/numero_2/?page=12 Repository e Pinning]}}
{{E-zine
|num=2
|articoli=[http://e-zine.debianizzati.org/web-zine/numero_2/?page=12 Repository & Pinning]
}}
= 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.


[[Categoria:Apt]] [[Categoria:Repository ufficiali]]
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.


{{Cautionbox|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]] o [[apt-get]].}}
{{Box|Importante|Il pinning è uno strumento per regolare la priorità in base al numero di versione dei pacchetti, e non alla 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>/etc/apt/sources.list</code>.}}


== MANUTENERE DEBIAN ==
= 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:
* 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à '''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.


Dopo aver installato una Debian nasce il bisogno di aggiungere nuovi programmi e allo stesso tempo tenerla costantemente aggiornata.<br />
Piccolo esempio teorico. Si supponga quanto segue:
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.<br />
* si desidera installare il pacchetto "vattelapesca" appartenente alla propria [[release]] (si supponga [[testing]]);
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.
* 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]]/[[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;
* nel sistema è installata la versione 1.3 di "vattelapesca";
* non esiste un file <code>preferences</code> o comunque non è stata specificata una priorità per nessuna delle tre release considerate;
* non è stato dichiarato il parametro ''Default Release'' in un eventuale file <code>apt.conf</code>, ovvero non è stata definita una release obiettivo.


Struttura di una Debian.
Nel momento in cui l'utente esegue il comando <code>apt install vattelapesca</code> sarà assegnata una priorità di 500 ai "vattelapesca" di repoA, repoB e repoC.<br/>
Il pacchetto da repoC viene immediatamente scartato perché implicherebbe la retrocessione ([[downgrade]]) dello stesso. A questo punto APT sceglierà tra repoA e repoB in base alla versione, e quindi a essere installato sarà quello da repoB e non da repoA come desiderato.
Il problema evidentemente non può che esplodere quando si tenta di aggiornare tutti i pacchetti di sistema.


= 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>.


== VERSIONI ==
* 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 '''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 '''500 e 989''', il candidato sarà installato solo se non esistono candidati appartenenti alla release 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 release, per esempio testing, non significa aver definito la release obiettivo, che può essere solo definita manualmente dall'utente (il come sarà spiegato nella discussione del file <code>apt.conf</code>).
* Pin compreso tra '''990 e 999''', il candidato sarà installato solo se non esistono altri candidati con pin maggiore e se la versione eventualmente già installata non è superiore.
* Pin '''1000''' o superiore, il candidato sarà installato se non esistono altri candidati con pin maggiore, anche se ciò comportasse la retrocessione di versione ([[downgrade]]) del candidato.


{{Box|IMPORTANTE|Si noti che gli intervalli sopra specificati sono la diretta conseguenza della procedura di assegnamento automatico di APT.}}
Posto per esempio di assegnare priorità 44 al pacchetto "vattelapesca" di stable e contestualmente di non dichiarare alcuna priorità per i "vattelapesca" di testing e unstable (assunto che i tre repository siano in <code>sources.list</code>), un candidato vattelapesca di stable potrà essere installato solo se:
# 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.


'''Oldstable''': come si intuisce dal nome una vecchia stabile, supportata riguardo gli aggiornamenti per la sicurezza per un certo periodo di tempo in contemporanea alla stabile.
== Priorità in caso di aggiornamento ==
Se una versione di un pacchetto è già stata installata sul sistema, la lettura dei punteggi può generare confusione. In particolare si noti che:
* il [[downgrade]] è possibile solo con una priorità almeno pari a 1000, quindi sono ignorati tutti i repository con priorità minore di 1000 contenenti una versione inferiore a quella già 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.


'''Stable''': la versione stabile ufficiale che beneficia quotidianamente degli aggiornamenti riguardo la sicurezza. Questa è la versione raccomandata per macchine di produzione e server.
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é:
* la priorità della stable non è sufficiente al [[downgrade]], dato che servirebbe una priorità di almeno 1000, e pertanto il repository è ignorato;
* la versione dei backports è più recente di quella installata e la loro priorità è (almeno) pari a 100.


'''Testing''': la versione di sviluppo destinata a divenire la nuova Stable (secondo ultime fonti con cadenza biennale [http://www.debian.org/News/2009/20090729/wiki/Help:Link Debian News Links]), anch'essa usufruisce degli aggiornamenti per la sicurezza, destinata ad un uso desktop (soggetta a qualche bug) sconsigliata per server e macchine di produzione. Della testing non esistono immagini ufficiali, ma da http://cdimage.debian.org/cdimage/weekly-builds/ è possibile scaricare delle immagini settimanali.
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]].


'''Unstable (sid)''': il titolo dice tutto! Qui si trovano i pacchetti più recenti ma che ancora non sono stati abbastanza testati per passare in testing, quindi in questa versione di sviluppo è possibile trovare molti pacchetti con bug. L'uso è riservato a coloro che vogliono testare pacchetti recenti e sanno a cosa vanno incontro. Per questo ramo non esistono immagini.
== 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.


'''Experimental''': questa non è una release, non esiste nessuna immagine, non ha nessun supporto ed è riservata solamente a testare i pacchetti, è una vasca "pool" dove vengono immesse delle versioni di pacchetti recentissimi, l'uso è riservato solo per far dei test.
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.


== REPOSITORY ==
{{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.}}


Riguardo i pacchetti, Debian ha tre grandi vasche - pool.<br />
= /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]] e [[aptitude]] per dei brevi esempi contenenti alcuni dei parametri più comuni.<br/>
Per quanto riguarda il pinning l'unico parametro strettamente di rilievo è:


;main
<pre>APT::Default-Release "release_voluta";</pre>
:qui si trovano i pacchetti che rispettano la policy debian, la DFSG – Debian Free Sotware Guidelines, pacchetti totalmente free.
;contrib
:pacchetti free ma che hanno alcune dipendenze che non rispettano la DFSG
;non-free
:pacchetti binari disponibili ma licenza e codice sorgente non libero.
da questa premessa si evince che sia il tipo di versione (stable, testing o unstable) che la tipologia dei pacchetti (main, contrib o non-free) vengono lasciati scegliere all'utente. Altra cosa da tenere in considerazione è che in questi repository non vi è traccia di pacchetti multimediali(codec audio-video) che non rispettino la DFSG. A ciò pone rimedio un repository, mantenuto da un gruppo di sviluppatori: ''http://deb-multimedia.org/''.<br />


In una Debian-box il file che contiene tutte le "indicazioni" per la gestione del parco software è: ''/etc/atp/sources.list''.
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]], [[apt-get]] e [[aptitude]].


===COME CONFIGURARE I REPOSITORY PER DEBIAN ===
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).


==== STABLE ====
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. In questa guida ora '''si sconsiglia sempre''' l'uso di una <code>Default-Release</code>, per via dei cambiamenti introdotti a ''codename'' e ''suite'' di un repository di sicurezza a partire da Debian 11 ([[Bullseye]]).


{{Cautionbox|
* 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}}''.
* Questa direttiva fino a Debian 10 ([[Buster]]) ha influenzato la priorità del repository principale di una release, nonché di quella relativa alla sua sicurezza, motivo per cui era abbastanza utile in alcune situazioni, per esempio nel caso di '''buster''' avrebbe influenzato entrambi i repository: <br/> <code>deb {{APT-mirror}} buster main</code> <br/> <code>deb {{APT-mirror|security}} buster/updates main</code>
* A partire da Debian 11 ([[Bullseye]]) però il repository di sicurezza ha ''codename'' e ''suite'' propri: ''codename'''''-security''' e ''suite'''''-security''' rispettivamente; ossia nel caso di '''bullseye''': <br/> <code>deb {{APT-mirror|security}} bullseye'''-security''' main</code> <br/> E pertanto l'uso di una <code>Default-Release</code> '''non''' influenzerà più il repository di sicurezza, di fatto disabilitandolo!}}
Si noti inoltre che:
* Comandi del tipo <code>apt 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 -t release_taldeitali install pacchetto</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.


Per avere una Debian stable completamente Free, in /etc/apt/sources.list si deve avere:
{{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)}}
 
<pre>deb http://ftp.it.debian.org/debian/ stable main</pre>
 
e per una Debian stable con tutti i pacchetti disponibili:
 
<pre>deb http://ftp.it.debian.org/debian/ main contrib non-free</pre>
 
È da considerare che, per non intasare il server, si possono utilizzare altri mirror (vedi http://www.debian.org/mirror/list per una lista completa), oppure per trovare il mirror più performante usare ''netselect-apt''.<br />
 
Se si vogliono anche dei pacchetti ''multimedia'' contenenti codice non-free (pacchetti comunque presenti in Debian come ad esempio dei codec audio-video ma mancanti del codice incriminato, quindi con alcune funzioni limitate o mancanti) aggiungiamo il repository [http://deb-multimedia.org/ deb-multimedia], che è [http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2012-May/026678.html esterno e non ufficiale], con la riga seguente:
 
<pre>deb http://www.deb-multimedia.org stable main non-free</pre>
 
(ci sono anche dei [http://www.deb-multimedia.org/debian-m mirror]). Per aggiugere la chiave pubblica dei repository deb-multimedia dal terminale diamo i seguenti comandi:
 
<pre>apt-get update && apt-get install deb-multimedia-keyring</pre>
 
Considerato il lungo lasso di tempo che intercorre per il rilascio di una stable nasce la necessità di avere aggiornati alcuni pacchetti. Debian mette a disposizione un altro repository che si integra alla perfezione, ovvero ''http://backports.debian.org/'' da cui è possibile scaricare pacchetti più recenti che si integrano con il ramo ''stable''. Per usufruire di questo repository aggiungere in ''/etc/apt/sources.list'' la seguente riga:
 
<pre>deb http://ftp.it.debian.org/debian/ stable-backports main contrib non-free</pre>
 
Per installare un pacchetto dal repository ''backports'' procedere in questo modo:
 
<pre>apt-get -t stable-backports install nome_pacchetto</pre>
 
Riepilogando, per avere la disponibilità di tutti i pacchetti nel sources.list si deve avere:


= /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> di utilizzare soltanto uno dei file per il pinning. La sintassi generale è la seguente:
<pre>
<pre>
## Repository principale Stable
Package: nome pacchetto o espressione regolare
deb http://ftp.it.debian.org/debian/ stable main contrib non-free
Pin: parametro da usare per identificare la versione desiderata
 
Pin-Priority: numero
## Aggiornamenti di sicurezza
deb http://security.debian.org/ stable/updates main contrib non-free
 
## Aggiornamenti raccomandati
deb http://ftp.it.debian.org/debian/ stable-updates main contrib non-free
 
## Backports
deb http://ftp.it.debian.org/debian/ stable-backports main contrib non-free
 
## Deb-multimedia
deb http://www.deb-multimedia.org stable main non-free
</pre>
</pre>


==== TESTING ====
Un po' di esempi del tutto arbitrari:


Package: vlc
Pin: release a=testing
Pin-Priority: 991


Come detto precedentemente la versione Testing non ha un rilascio ufficiale, essendo costantemente aggiornata, ma si possono avere degli snapshot giornalieri o settimanali reperibili rispettivamente:
Package: vlc
Pin: release n={{Codename|testing}}
Pin-Priority: 991


- ''immagini giornaliere ''
Package: virtualbox4*
Pin: Release o=Oracle Corporation
Pin-Priority: 780


<pre>http://cdimage.debian.org/cdimage/daily-builds/ </pre>
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''.


- ''immagini settimanali''
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.


<pre>http://cdimage.debian.org/cdimage/weekly-builds/</pre>
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".
È utile infine evidenziare un paragrafo del manuale di ''apt_preferences'':


{{Box|Importante|''Se almeno un record in forma specifica corrisponde ad una versione di pacchetto disponibile, allora il primo di questi record determina la priorità della versione del pacchetto. In caso contrario, se almeno un record in forma generica corrisponde ad una versione di pacchetto disponibile, allora il primo di questi record determina la priorità della versione del pacchetto.''}}


{{ Warningbox | le immagini possono soffrire di qualche bug e l'installazione può interrompersi e non terminare correttamente. Per non aver problemi far riferimento alla STABLE}}  
{{Suggerimento|Specificare nel file <code>sources.list</code> sempre per primi il o i repository principali della release obiettivo.}}


{{Box|File multipli|È possibile creare più file di nome arbitrario in ''/etc/apt/apt.preferences.d/'' invece di creare un unico file di nome ''preferences'',  (si veda il manuale).}}


Quindi per avere una Debian Testing ci sono due possibilità:
== Blocco/retrocessione di pacchetti ==
 
Il file <code>preferences</code> può essere usato per bloccare e/o retrocedere ([[downgrade]]) uno o più pacchetti (al limite tutti); in entrambi i casi è necessario definire un pin maggiore o uguale a 1000 per il pacchetto desiderato. Se per esempio nel file <code>preferences</code> fosse presente un record come il seguente:
* Usare una delle immagini giornaliere o settimanali;
* Fare un upgrade della Stable a Testing.
 
Per il primo punto scaricare l'immagine iso, masterizzarla su un cd vergine e proseguire con l'installazione comune.
 
Per una guida grafica consultare: [[Installare Debian Lenny - Guida Grafica]]
 
oppure [http://e-zine.debianizzati.org/ il numero 0 della e-zine].<br>
 
Riguardo l'upgrade da Stable a Testing bisogna modificare il file /etc/apt/sources.list aggiungendo i repository della Testing ovvero:
 
<pre>deb http://ftp.it.debian.org/debian/ testing main</pre>
 
ovviamente come per la Stable se si vogliono abilitati tutti i repository, contrib non-free e multimedia si deve avere il file /etc/apt/sources.list nella seguente maniera (ma meglio abilitarli tutti '''solo dopo''' aver effettuato l'upgrade da stable a testing):


<pre>
<pre>
## Repository principale Testing
Package: nome_pacchetto
deb http://ftp.it.debian.org/debian/ testing main contrib non-free
Pin: version 1.0.1
 
Pin-Priority: 1001
## Aggiornamenti di sicurezza
deb http://ftp.it.debian.org/debian/ testing/updates main contrib non-free
 
## Deb-multimedia
deb http://www.deb-multimedia.org testing main non-free
</pre>
</pre>


a seguito del comando <code>apt-get install nome_pacchetto</code> si avrebbero i seguenti due casi:
# Se nel sistema non esiste una versione del suddetto pacchetto oppure se già installato la sua versione è più vecchia di 1.0.1, allora il pacchetto viene aggiornato normalmente, ma una volta terminata l'installazione questo pacchetto non verrà mai più aggiornato.
# Se il pacchetto è già stato installato e la sua versione è più recente di 1.0.1 allora il pacchetto presente nel sistema viene disinstallato e sostituito con quello avente versione 1.0.1. Terminata l'installazione il pacchetto non verrà mai più aggiornato.
Per permettere nuovamente l'aggiornamento del pacchetto è necessario eliminare il record.


Salvato il file si procede con:
Per maggiori informazioni si consulti la guida [[Fare il downgrade di uno o più pacchetti]].


<pre>apt-get update
{{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!'''


apt-get install apt dpkg aptitude
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.}}


aptitude safe-upgrade
= Esempi senza bisogno di pinning =


aptitude full-upgrade</pre>
== Release pura ==
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>.


Infatti ciò avrebbe effetto sul repository principale e su quello della sicurezza (solo fino a Debian 10 [[Buster]]), 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>.
E a partire da Debian 11 ([[Bullseye]]) perfino gli aggiornamenti di sicurezza sarebbero bloccati!


Giunti a questo punto si dovrebbe essere in Debian Testing. Essendo Testing in continua evoluzione si raccomanda di fare spesso degli upgrade.
== 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.


{{ Warningbox | maggiore è il lasso di tempo tra il rilascio della Stable e la Testing, maggiori sono le possibilità di fallimento nell'upgrade. Solo dopo il rilascio della nuova Stable è assicurato l'upgrade }}
Per installare un pacchetto dai backports la prima volta, basta utilizzare [[apt]] (o equivalentemente [[apt-get]]):
# apt -t {{Codename|stable}}-backports install nomepacchetto


==== UNSTABLE ====
Per esempio per installare <code>libreoffice</code>:
 
# apt -t {{Codename|stable}}-backports install libreoffice
 
Per fare un upgrade alla versione Debian Unstable, come detto non esistono immagini ufficiali, quindi bisogna partire da una Testing o da una installazione del sistema base (netinstall, businesscard), quindi modificare /etc/apt/sources.list aggiungendo i repository per Unstable:


Dopo di che sarà aggiornato automaticamente assieme agli altri pacchetti di {{Codename|Stable}} con:
<pre>
<pre>
## Repository principale Unstable
# apt update
deb http://ftp.it.debian.org/debian/ unstable main contrib non-free
# apt upgrade
 
## Deb-multimedia
deb http://www.deb-multimedia.org unstable main non-free
</pre>
</pre>
Si noti invece che potrebbe essere necessario un <code>dist-upgrade</code> se si utilizza [[apt-get]].


=== Backports automatici ===
{{Cautionbox | Questo esempio '''non''' è consigliato, ma intende soltanto mostrare alcune delle problematiche nella configurazione del pinning.


Salvato il file si procede con:
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.}}
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.


<pre>apt-get update
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.


apt-get install apt dpkg aptitude
Le principali alternative, presentate a solo scopo didattico:
* nessuna <code>Default-Release</code> in <code>apt.conf</code> e file <code>/etc/apt/preferences</code> come segue
Package: libreoffice
Pin: release n={{Codename|stable}}-backports
Pin-Priority: 500
* nessuna <code>Default-Release</code> in <code>apt.conf</code> e file <code>/etc/apt/preferences</code> come segue
Package: libreoffice*
Pin: release n={{Codename|stable}}-backports
Pin-Priority: 500
* nessuna impostazione in <code>/etc/apt/preferences</code> e file <code>/etc/apt/apt.conf</code> come segue
APT::Default-Release "{{Codename|stable}}-backports";


aptitude safe-upgrade
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>.


aptitude full-upgrade</pre>
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.


si può far riferimento alla guida [[Installare Debian SID]]
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]].


{{ Warningbox | L'uso di Unstable può compromettere la funzionalità del Sistema Operativo, siate consci di quello che state facendo }}
{{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>).


== PINNING ==
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).}}


Abbiamo visto come poter avere una Debian Stable, Testing o Unstable adattando i repository all'uopo. Però, usando una Stable o una Testing potrebbe nascere l'esigenza di bloccare un pacchetto o volerlo aggiornare ad una versione che si trova in un ramo superiore senza compromettere la stabilità e la funzionalità della versione che si sta utilizzando o addirittura fare un downgrade di un pacchetto o dell'intera versione (caso molto delicato). Per far ciò Debian utilizza un meccanismo molto sofisticato, chiamato ''pinning'', che permette di assegnare ai vari pacchetti una priorità per l'installazione indipendentemente dal ramo o versione di cui fanno parte (stable, testing, unstable, experimental).<br />
== Unstable/Sid ed experimental ==
Per far ciò è possibile agire su uno o entrambi i seguenti due file testuali: <code>/etc/apt/apt.conf</code> e <code>/etc/apt/preferences</code>. Di norma questi due file non sono presenti dopo un'installazione, è pertanto l'utente a doverli creare ex-novo utilizzando un qualsiasi editor di testo.<br/>
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.
Si noti che entrambi i file devono essere definiti secondo precise regole e direttive di cui si mostreranno solo alcuni elementi base, giusto per aver un minimo di funzionalità.


{{ Warningbox | Considerata la complessità dell'argomento, questo mini how-to ha il solo scopo all'introduzione di questa procedura, per un uso avanzato far riferimento a [http://manpages.debian.net/man/5/apt.conf man apt.conf] e [http://manpages.debian.net/man/5/apt_preferences man apt_preferences]}}
Per installare o aggiornare un pacchetto da experimental, basta eseguire:
<pre># apt -t experimental install nomepacchetto</pre>


=== /etc/apt/apt.conf ===
= Esempi con pinning =


Delle innumerevoli direttive che è possibile dichiarare solo la seguente interessa la procedura di pinning
== Stable con testing ==
{{Cautionbox | Senza pinning ci si troverebbe con una testing effettuando gli aggiornamenti del sistema.


<pre>APT::Default-Release</pre>
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.}}
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.


ad esempio  
=== sources.list ===
{{Cautionbox | Si ricorda che a partire da Debian 11 ([[Bullseye]]) i repository di sicurezza andranno scritti con la dicitura ''release'''''-security''' (anziché ''release'''''/updates'''); per esempio nel caso di bullseye:
deb {{APT-mirror|security}} bullseye'''-security''' main }}
# Stable
deb {{APT-mirror}} {{Codename|stable}} main
deb-src {{APT-mirror}} {{Codename|stable}} main
# Aggiornamenti di sicurezza
deb {{APT-mirror|security}} {{Codename|stable}}{{#ifeq: {{Codename|stable}} | buster | /updates | -security }} main
deb-src {{APT-mirror|security}} {{Codename|stable}}{{#ifeq: {{Codename|stable}} | buster | /updates | -security }} main
# Aggiornamenti raccomandati
deb {{APT-mirror}} {{Codename|stable}}-updates main
deb-src {{APT-mirror}} {{Codename|stable}}-updates main
# Backports
deb {{APT-mirror}} {{Codename|stable}}-backports main
deb-src {{APT-mirror}} {{Codename|stable}}-backports main
# Testing
deb {{APT-mirror}} {{Codename|testing}} main
deb-src {{APT-mirror}} {{Codename|testing}} main
# Aggiornamenti di sicurezza di testing
deb {{APT-mirror|security}} {{Codename|testing}}-security main
deb-src {{APT-mirror|security}} {{Codename|testing}}-security main


<pre>APT::Default-Release "stable"; </pre>
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]]).


impone ad apt di considerare la release stable come release di riferimento, attribuendogli un punteggio di 990 (si veda più avanti per una spiegazione del significato dei vari punteggi).
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.


{{Box|Nota|Per quanto riguarda tutti i pacchetti della release target 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à.}}
=== 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.


Premesso questo in </code>/etc/apt/apt.conf</code> si daranno le seguenti indicazioni:
=== 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


- della versione che si vuole utilizzare come default (stable)<br>
Questa configurazione si consiglia soltanto per pacchetti che non richiedono l'installazione di altri da testing.
- della dimensione della cache<br>
- del purge dei pacchetti<br>
- della pulizia della cache<br>
- del fix dei pacchetti rotti (causa dipendenze non soddisfatte)<br>
- del fix dei pacchetti non possibili da installare<br>
- di mostrare gli upgrade dei pacchetti<br>
- di forzare il loop dei pacchetti rotti (causa dipendenze non soddisfatte)<br>
- di permettere l'installazione di pacchetti non autenticati (manca la chiave pubblica)<br>
 
quindi il file <code>preferences</code> apparirà come segue


Si può controllarne il funzionamento con:
<pre>
<pre>
  APT::Default-Release "stable";
$ apt-get --simulate install nomepacchetto
 
</pre>
  APT::Cache-Limit 24000000;
(e si può usare la forma abbreviata <code>-s</code> al posto di <code>--simulate</code>)
 
  Apt::Get::Purge;
 
  APT::Clean-Installed;
 
  APT::Get::Fix-Broken;
 
  APT::Get::Fix-Missing;
 
  APT::Get::Show-Upgraded "true";
 
  APT::Force-LoopBreak=true;
 
  APT::Get::AllowUnauthenticated 1;</pre>
 
{{Box|Nota|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)}}.
 
=== /etc/apt/preferences ===
 
Prima di vedere la sintassi per strutturare il file cerchiamo di capire il valore che la policy Debian assegna ad un singolo pacchetto o alla release (stable o testing) in generale:<br/>
<br/>
'''Valore del PIN:'''<br/>
- superiore a '''1000''' ha l'assoluta priorità nell'installazione può implicare il downgrade<br/>
- da '''991 a 1000''' il pacchetto verrà installato anche se non fa parte della release (specificata in apt.conf), a meno che la versione installata sia più recente<br/>
- da '''551 a 990''' il pacchetto verrà installato a meno che ci sia disponibile una versione che fa parte della release (specificata in apt.conf) o che la versione installata sia più recente<br/>
- da '''101 a 550''' il pacchetto verrà installato a meno che ci sia disponibile una versione appartenente a qualsiasi release o che la versione installata sia più recente<br/>
- da '''0 a 100''' il pacchetto viene installato solo se non è installata nessuna versione del pacchetto<br/>
- minore di '''0''' previene l'installazione del pacchetto, qualsiasi sia l'origine<br/>
<br/>
Avendo visto il valore del PIN possiamo adattare il nostro file ''/etc/apt/preferences'' ai nostri bisogni, bloccando o retrocedendo oppure aggiornando i vari pacchetti. Da tenere in considerazione che se usiamo una stable ed installiamo un pacchetto da testing o unstable non avremo più la garanzia che essa ci offre.<br/><br/>
 
{{Box|Nota|Similmente al caso precedente è possibile creare più file di nome arbitrario in ''/etc/apt/apt.preferences.d/'' invece di creare un unico file di nome ''preferences'',  (si veda il manuale).}}
 
Qualche esempio pratico.<br/>
<br/>
Fondamentale aver creato il file '''/etc/apt/apt.conf''' (dove avremo specificato la nostra release preferita: stable o testing) e aver abilitato tutti i repository delle diverse release in '''/etc/apt/sources.list'''


In assenza di problemi, sarà possibile installare il pacchetto "nomepacchetto" da testing semplicemente con:
<pre>
<pre>
deb http://ftp.it.debian.org/debian/ stable main contrib non-free
# apt install nomepacchetto
 
deb http://www.deb-multimedia.org stable main non-free
 
deb http://ftp.it.debian.org/debian/ stable-backports main contrib non-free
 
deb http://security.debian.org/ stable/updates main contrib non-free
 
deb http://ftp.it.debian.org/debian/ stable-updates main contrib non-free
 
deb http://ftp.it.debian.org/debian/ testing main contrib non-free
 
deb http://www.deb-multimedia.org stable main non-free
 
deb http://ftp.it.debian.org/debian/ unstable main contrib non-free
 
deb http://www.deb-multimedia.org unstable main non-free
</pre>
</pre>


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.


Ovviamente chi usa Testing può omettere i repository della Stable.<br/>
{{Cautionbox | Infatti mentre sarebbe possibile forzarne l'installazione con:
<br/>
# apt -t {{Codename|testing}} install nomepacchetto
Ora possiamo vedere la policy Debian riguardo alle release:
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).}}
=== 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.


<pre>apt-cache policy</pre>
Si noti che i valori scelti non sono gli unici possibili. L'importante è che siano soddisfatte le seguenti condizioni:
* ''{{Codename|stable}}-backports'' deve avere una priorità inferiore a quella di default (500), utilizzata per ''{{Codename|stable}}'' e ''{{Codename|stable}}-updates'';
* ''{{Codename|testing}}'' deve avere una priorità inferiore a quella scelta per ''{{Codename|stable}}-backports'';
* ''{{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.


ci restituirà il PIN delle release, giusto per farci un'idea.<br />
Ora basterà:
Lo stesso per vedere la policy di un singolo pacchetto  es:
# apt -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.


<pre>apt-cache policy nano</pre>
== Testing con unstable ed experimental ==
<!--
  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]].


=== STABLE ===
=== sources.list ===
deb {{APT-mirror}} testing main
deb-src {{APT-mirror}} testing main
# Aggiornamenti di sicurezza
deb {{APT-mirror|security}} testing-security main
deb-src {{APT-mirror|security}} testing-security main
# Unstable
deb {{APT-mirror}} sid main
deb-src {{APT-mirror}} sid main
# Experimental
deb {{APT-mirror}} experimental main
deb-src {{APT-mirror}} experimental main


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]].


Prendiamo in considerazione di lavorare con una Stable e il file preferences nel seguente modo
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.
 
<pre>
Package: *
Pin: release a=stable
Pin-Priority: 900


Package: *
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> .
Pin: release o=Debian
Pin-Priority: -10
</pre>


Cerchiamo di capire il significato delle tre righe:
=== apt.conf ===
Assicurarsi che '''non''' sia impostata una <code>Default-Release</code> per non disabilitare gli aggiornamenti di sicurezza ('''testing-security''').


'''Package: *'''  vuol dire tutti i pacchetti<br>
[[Testing]] tipicamente non riceve comunque aggiornamenti di sicurezza da questo repository, se non quando non è possibile il porting da [[Sid]], ma è sempre meglio tenerlo abilitato.
'''Pin: release a=stable''' tutti i pacchetti della Suite (a) stable<br>
'''Pin-Priority: 900''' verranno installati solo pacchetti più aggiornati della stessa release (se ce ne sono)<br>
<br>     
mentre<br>


'''Package: *''' vuol dire tutti i pacchetti<br>
=== preferences ===
'''Pin: release o=Debian''' pacchetti di Origin (o) Debian<br>
In questo modo entrambi i repository '''testing''' e '''testing-security''' avranno priorità maggiore di '''sid''':
'''Pin-Priority: -10''' nessuna priorità<br>
<br>
In questo caso verranno installati solo pacchetti più aggiornati della stessa release (se ce ne sono) e nessun altro pacchetto di release diverse verrà installato.<br/>
Se si vuole installare un pacchetto proveniente dalla release Testing si possono usare due comandi:


<pre>apt-get install nome_pacchetto/testing</pre>
Package: *
Pin: release a=testing-security
Pin-Priority: 990
Package: *
Pin: release a=testing
Pin-Priority: 990


(''installerà il pacchetto con le dipendenze della stable'')
Si noti che questa configurazione era equivalente a impostare la <code>Default-Release</code> a '''testing''' nel file <code>/etc/apt/apt.conf</code>, prima dei cambiamenti a [[codename]] e [[suite]] dei repository di sicurezza introdotti con Debian 11 ([[Bullseye]]).


<pre>apt-get install -t testing nome_pacchetto</pre>
Alternativamente sarebbe possibile anche impostare una priorità inferiore per '''sid''', purché almeno uguale a '''100'''. Per esempio:
Package: *
Pin: release n=sid
Pin-Priority: 100


''(installerà il pacchetto con le dipendenze della release testing. Il pacchetto non verrà più aggiornato fino a quando non ridaremo lo stesso comando)''<br/>
Con entrambe le configurazioni il repository di '''sid''' sarebbe equivalente a quello dei [[Il repository Backports|backports]]; ossia verrebbe consentito l'aggiornamento automatico dei pacchetti installati, ma non l'installazione automatica di nuovi pacchetti (se presenti anche in '''testing''').
<br/>
{{ Warningbox | Considerata la stabilità della release Stable, usare pacchetti di altre release potrebbe comprometterne la stabilità. Per avere una perfetta integrazione con Stable meglio usare il pinning con i pacchetti provenienti dai backports }}


Se, ad esempio, volessimo installare la versione più recente di ''libreoffice'' dai ''backports'':  
=== 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 -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 upgrade</code> o <code>apt full-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 -t experimental install nomepacchetto</code>


<pre>apt-get -t stable-backports install libreoffice</pre>
== 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.


per evitare che nei prossimi upgrades il pacchetto venga retrocesso alla versione della ''Stable'' nel file preferences aggiungere:
{{Box|Nota|Questo esempio non permette di retrocedere automaticamente pacchetti già installati da deb-multimedia.}}


<pre>Package: libreoffice
=== sources.list ===
Pin: release a=stable-backports
Abilitiamo anche le sezioni ''contrib'' e ''non-free'':
Pin-Priority: 999</pre>


In questo modo rimarrà installata la versione del Backports.<br/>
# Debian testing
<br/>
deb {{APT-mirror}} testing main contrib non-free
Come detto precedentemente in questa maniera possiamo fare il downgrade sia di un pacchetto o dell'intera release, basta agire sul file preferences indicando il pacchetto o la release modificando il Pin-Priority.<br/>
Vediamo qualche esmpio concreto.<br/>
# Debian testing - sicurezza
<br/>
deb {{APT-mirror|security}} testing-security main contrib non-free
''ES. n° 1'' voglio il ''pacchetto-1.0.1''  indipendentemente dalla release che utilizzo
  # repository NON ufficiali - multimedia
deb http://www.deb-multimedia.org testing main non-free


<pre>
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.
Package: pacchetto
Pin: version 1.0.1
Pin-Priority: 1001
</pre>


in questo modo  ''pacchetto'' versione ''1.0.1'' non verrà mai scalzato né da una versione più recente né da una più vecchia (in caso di downgrade).<br/>
=== apt.conf ===
<br/>
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.
''ES. n° 2'' fare il downgrade di una release (questo passaggio è molto delicato, usatelo con cautela):


=== preferences ===
<pre>
<pre>
Package: *
Package: *
Pin: release a=stable
Pin: Release o=Unofficial Multimedia Packages
Pin-Priority: 1001
Pin-Priority: 100
 
Package: *
Pin: release o=Debian
Pin-Priority: -10
</pre>
</pre>


in questo modo basta
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.
 
<pre>aptitude update
aptitude safe-upgrade
aptitude full-upgrade</pre>
 
similmente con apt:
 
<pre>apt-get update
apt-get upgrade
apt-get dist-upgrade</pre>
 
=== TESTING ===
 
Se si sta utilizzando Testing e si ha l'esigenza di installare un pacchetto da Unstable o Experimental (usare con molta cautela), come visto sopra creiamo i due files '''/etc/apt/apt.conf''' e '''/etc/apt/preferences''' come segue:<br/>
<br/>
'''/etc/apt/apt.conf'''
<pre>
  APT::Default-Release "testing";
 
  APT::Cache-Limit 24000000;
 
  Apt::Get::Purge;
 
  APT::Clean-Installed;
 
  APT::Get::Fix-Broken;
 
  APT::Get::Fix-Missing;
 
  APT::Get::Show-Upgraded "true";
 
  APT::Force-LoopBreak=true;
 
  APT::Get::AllowUnauthenticated 1;</pre>
 
 


'''/etc/apt/preferences'''
=== Osservazioni ===
<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.
Package: *
* 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.
Pin: release a=testing
Pin-Priority: 800


Package: *
= Comandi utili =
Pin: release a=unstable
È possibile visualizzare l'elenco delle priorità relative a tutti i repository e pacchetti dichiarati con [[apt-cache]]:
Pin-Priority: 600
<pre>$ apt-cache policy</pre>
 
Package: *
Pin: release a=experimental
Pin-Priority: 50
 
Package: *
Pin: release o=Debian
Pin-Priority: -10
</pre>


Questo farà in modo che apt installi di default i pacchetti provenienti dalla release ''Testing''.<br/>
Se si volesse visualizzare solo la priorità per un singolo singolo pacchetto, ad esempio nano, si può digitare:
Se si vogliono installare pacchetti provenienti da ''Unstable'' o ''Experimental'':
<pre>$ apt-cache policy nano</pre>


<pre>apt-get install nome_pacchetto/unstable</pre>
Si consiglia anche l'installazione di [[apt-show-versions]], per poter controllare velocemente da quali repository provengono i pacchetti installati sul sistema.


''questo installerà il pacchetto con le dipendenze della testing''
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.


<pre>apt-get install -t unstable nome_pacchetto</pre>
= Approfondimenti =
=== Manpages ===
<code>man apt.conf</code><br/>
<code>man apt_preferences</code>


''questo installerà il pacchetto con le dipendenze della release unstable''<br />
{{Autori
<br/>
|Autore = [[User:Xtow|Xtow]]
Per quanto riguarda il mantenimento o il downgrade di un pacchetto specifico operare come indicato sopra nella sezione STABLE.
|Estesa_da =
: [[Utente:Wtf|Wtf]]
: [[Utente:HAL 9000|HAL 9000]]
|Verificata_da =
: [[Utente:Wtf|Wtf]]
: [[Utente:HAL 9000|HAL 9000]] 15:58, 3 ago 2019 (CEST)
|Numero_revisori = 2
}}


[[Categoria:E-zine]]
[[Categoria:Apt]][[Categoria:E-zine]][[Categoria:Repository ufficiali]]

Versione attuale delle 13:37, 4 ago 2019

I repository
Arrow left.png

Introduzione ai repository

Repository ufficiali di Debian

Repository esterni

Extra

Arrow right.png



Debian-swirl.png Versioni Compatibili

Tutte le versioni supportate di Debian
Banner e-zine.png
Questa guida è basata sui seguenti articoli presenti all'interno del numero 2 dell'e-zine di Debianizzati.org :

Repository & Pinning


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.

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.

Attention.png Avvertimento
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 o apt-get.
Info.png Importante
Il pinning è uno strumento per regolare la priorità in base al numero di versione dei pacchetti, e non alla 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 /etc/apt/sources.list.


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:

  • 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à 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.

Piccolo esempio teorico. Si supponga quanto segue:

  • 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 sources.list;
  • 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;
  • nel sistema è installata la versione 1.3 di "vattelapesca";
  • non esiste un file preferences o comunque non è stata specificata una priorità per nessuna delle tre release considerate;
  • non è stato dichiarato il parametro Default Release in un eventuale file apt.conf, ovvero non è stata definita una release obiettivo.

Nel momento in cui l'utente esegue il comando apt install vattelapesca sarà assegnata una priorità di 500 ai "vattelapesca" di repoA, repoB e repoC.
Il pacchetto da repoC viene immediatamente scartato perché implicherebbe la retrocessione (downgrade) dello stesso. A questo punto APT sceglierà tra repoA e repoB in base alla versione, e quindi a essere installato sarà quello da repoB e non da repoA come desiderato. Il problema evidentemente non può che esplodere quando si tenta di aggiornare tutti i pacchetti di sistema.

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.
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 sources.list.

  • 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 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 500 e 989, il candidato sarà installato solo se non esistono candidati appartenenti alla release 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 release, per esempio testing, non significa aver definito la release obiettivo, che può essere solo definita manualmente dall'utente (il come sarà spiegato nella discussione del file apt.conf).
  • Pin compreso tra 990 e 999, il candidato sarà installato solo se non esistono altri candidati con pin maggiore e se la versione eventualmente già installata non è superiore.
  • Pin 1000 o superiore, il candidato sarà installato se non esistono altri candidati con pin maggiore, anche se ciò comportasse la retrocessione di versione (downgrade) del candidato.
Info.png IMPORTANTE
Si noti che gli intervalli sopra specificati sono la diretta conseguenza della procedura di assegnamento automatico di APT.

Posto per esempio di assegnare priorità 44 al pacchetto "vattelapesca" di stable e contestualmente di non dichiarare alcuna priorità per i "vattelapesca" di testing e unstable (assunto che i tre repository siano in sources.list), un candidato vattelapesca di stable potrà essere installato solo se:

  1. Non esistono altri candidati dello stesso pacchetto provenienti dalle altre fonti, infatti APT assegnerebbe a loro automaticamente una priorità di 500 (500 > 44).
  2. 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.

Priorità in caso di aggiornamento

Se una versione di un pacchetto è già stata installata sul sistema, la lettura dei punteggi può generare confusione. In particolare si noti che:

  • il downgrade è possibile solo con una priorità almeno pari a 1000, quindi sono ignorati tutti i repository con priorità minore di 1000 contenenti una versione inferiore a quella già 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.
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 versione dei backports è più recente di quella installata e la loro priorità è (almeno) pari a 100.

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.

Info.png 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

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.
Per quanto riguarda il pinning l'unico parametro strettamente di rilievo è:

APT::Default-Release "release_voluta";

che equivale alla dichiarazione in riga di comando dell'opzione -t release_voluta (anche nella forma --target-release release_voluta) in apt, apt-get e aptitude.

Tale dichiarazione:

  • attribuisce priorità 990 a tutti i pacchetti appartenenti alla release specificata;
  • ignora tutte le impostazioni di pinning in /etc/apt/preferences 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 Default-Release se si vuole utilizzare anche il file /etc/apt/preferences, per non creare conflitti tra le due configurazioni. In questa guida ora si sconsiglia sempre l'uso di una Default-Release, per via dei cambiamenti introdotti a codename e suite di un repository di sicurezza a partire da Debian 11 (Bullseye).

Attention.png Avvertimento
  • 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 bookworm.
  • Questa direttiva fino a Debian 10 (Buster) ha influenzato la priorità del repository principale di una release, nonché di quella relativa alla sua sicurezza, motivo per cui era abbastanza utile in alcune situazioni, per esempio nel caso di buster avrebbe influenzato entrambi i repository:
    deb http://deb.debian.org/debian/ buster main
    deb http://security.debian.org/debian-security buster/updates main
  • A partire da Debian 11 (Bullseye) però il repository di sicurezza ha codename e suite propri: codename-security e suite-security rispettivamente; ossia nel caso di bullseye:
    deb http://security.debian.org/debian-security bullseye-security main
    E pertanto l'uso di una Default-Release non influenzerà più il repository di sicurezza, di fatto disabilitandolo!

Si noti inoltre che:

  • Comandi del tipo apt install pacchetto/release_taldeitali 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 apt.conf 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 apt -t release_taldeitali install pacchetto disabilita durante l'esecuzione qualunque release obiettivo (Default-Release) dichiarata nel file apt.conf. Perciò avere un pinning a 990 in preferences non è necessariamente equivalente a impostare una Default-Release, anche in assenza di conflitti tra i due file di configurazione.
Info.png 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)


/etc/apt/preferences

Questo è il file dove è possibile definire tutte le priorità che si vogliono, fermo restando quanto detto nella sezione dedicata ad apt.conf di utilizzare soltanto uno dei file per il pinning. La sintassi generale è la seguente:

Package: nome pacchetto o espressione regolare
Pin: parametro da usare per identificare la versione desiderata
Pin-Priority: numero

Un po' di esempi del tutto arbitrari:

Package: vlc
Pin: release a=testing
Pin-Priority: 991
Package: vlc
Pin: release n=trixie
Pin-Priority: 991
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 archive) mentre il secondo al codename (nome in codice). In entrambi si è definito il pinning per il pacchetto di nome "vlc", richiedendo che le versioni appartenenti alla release testing, attualmente trixie, abbiano priorità 991. Attenzione però che quando trixie diverrà la nuova stable, il primo si applicherà alla nuova testing mentre il secondo continuerà a far riferimento a trixie. 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 /etc/apt/sources.list, 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". È utile infine evidenziare un paragrafo del manuale di apt_preferences:

Info.png Importante
Se almeno un record in forma specifica corrisponde ad una versione di pacchetto disponibile, allora il primo di questi record determina la priorità della versione del pacchetto. In caso contrario, se almeno un record in forma generica corrisponde ad una versione di pacchetto disponibile, allora il primo di questi record determina la priorità della versione del pacchetto.


Bulb.png Suggerimento
Specificare nel file sources.list sempre per primi il o i repository principali della release obiettivo.


Info.png File multipli
È possibile creare più file di nome arbitrario in /etc/apt/apt.preferences.d/ invece di creare un unico file di nome preferences, (si veda il manuale).


Blocco/retrocessione di pacchetti

Il file preferences può essere usato per bloccare e/o retrocedere (downgrade) uno o più pacchetti (al limite tutti); in entrambi i casi è necessario definire un pin maggiore o uguale a 1000 per il pacchetto desiderato. Se per esempio nel file preferences fosse presente un record come il seguente:

Package: nome_pacchetto
Pin: version 1.0.1
Pin-Priority: 1001

a seguito del comando apt-get install nome_pacchetto si avrebbero i seguenti due casi:

  1. Se nel sistema non esiste una versione del suddetto pacchetto oppure se già installato la sua versione è più vecchia di 1.0.1, allora il pacchetto viene aggiornato normalmente, ma una volta terminata l'installazione questo pacchetto non verrà mai più aggiornato.
  2. Se il pacchetto è già stato installato e la sua versione è più recente di 1.0.1 allora il pacchetto presente nel sistema viene disinstallato e sostituito con quello avente versione 1.0.1. Terminata l'installazione il pacchetto non verrà mai più aggiornato.

Per permettere nuovamente l'aggiornamento del pacchetto è necessario eliminare il record.

Per maggiori informazioni si consulti la guida Fare il downgrade di uno o più pacchetti.

Warning.png ATTENZIONE
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!

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.


Esempi senza bisogno di pinning

Release pura

Non serve il pinning se si usano i repository ufficiali o quelli speciali di una sola release di Debian, ed è sconsigliato anche impostare una Default-Release in apt.conf.

Infatti ciò avrebbe effetto sul repository principale e su quello della sicurezza (solo fino a Debian 10 Buster), 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 Default-Release. E a partire da Debian 11 (Bullseye) perfino gli aggiornamenti di sicurezza sarebbero bloccati!

Stable con backports

Non è necessario alcun pinning nemmeno aggiungendo i backports ai repository della stable (attualmente bookworm), 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.

Per installare un pacchetto dai backports la prima volta, basta utilizzare apt (o equivalentemente apt-get):

# apt -t bookworm-backports install nomepacchetto

Per esempio per installare libreoffice:

# apt -t bookworm-backports install libreoffice

Dopo di che sarà aggiornato automaticamente assieme agli altri pacchetti di bookworm con:

# apt update
# apt upgrade

Si noti invece che potrebbe essere necessario un dist-upgrade se si utilizza apt-get.

Backports automatici

Attention.png Avvertimento
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.

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. È 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.

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.

Le principali alternative, presentate a solo scopo didattico:

  • nessuna Default-Release in apt.conf e file /etc/apt/preferences come segue
Package: libreoffice
Pin: release n=bookworm-backports
Pin-Priority: 500
  • nessuna Default-Release in apt.conf e file /etc/apt/preferences come segue
Package: libreoffice*
Pin: release n=bookworm-backports
Pin-Priority: 500
  • nessuna impostazione in /etc/apt/preferences e file /etc/apt/apt.conf come segue
APT::Default-Release "bookworm-backports";

La prima possibilità restituisce errore quando si cerca di installare il pacchetto, costringendo a ricorrere all'opzione -t 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 -t.

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.

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.

Info.png Backports obbligatori
Specificando una priorità di 990 anziché 500 nel file /etc/apt/preferences, come visto in questa sezione, l'installazione di libreoffice dai repository non backports fallirebbe anche utilizzando l'opzione -t bookworm, rendendo l'installazione da bookworm-backports l'unica possibile (anche se non garantita senza l'uso dell'opzione -t bookworm-backports).

Si noti invece che l'uso dei backports non è obbligatorio specificando la Default-Release a bookworm-backports, per le ragioni già esposte nella sezione su apt.conf di questa guida, anche se lo sarebbero gli aggiornamenti (in assenza di conflitti con le dipendenze).


Unstable/Sid ed experimental

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.

Per installare o aggiornare un pacchetto da experimental, basta eseguire:

# apt -t experimental install nomepacchetto

Esempi con pinning

Stable con testing

Attention.png Avvertimento
Senza pinning ci si troverebbe con una testing effettuando gli aggiornamenti del sistema.

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.

Per prima cosa si devono aggiungere i repository di testing. Di seguito sono esaminate diverse possibilità di pinning, in base alla configurazione desiderata.

sources.list

Attention.png Avvertimento
Si ricorda che a partire da Debian 11 (Bullseye) i repository di sicurezza andranno scritti con la dicitura release-security (anziché release/updates); per esempio nel caso di bullseye:
deb http://security.debian.org/debian-security bullseye-security main 
# Stable
deb http://deb.debian.org/debian/ bookworm main
deb-src http://deb.debian.org/debian/ bookworm main

# Aggiornamenti di sicurezza
deb http://security.debian.org/debian-security bookworm-security main
deb-src http://security.debian.org/debian-security bookworm-security main

# Aggiornamenti raccomandati
deb http://deb.debian.org/debian/ bookworm-updates main
deb-src http://deb.debian.org/debian/ bookworm-updates main

# Backports
deb http://deb.debian.org/debian/ bookworm-backports main
deb-src http://deb.debian.org/debian/ bookworm-backports main

# Testing
deb http://deb.debian.org/debian/ trixie main
deb-src http://deb.debian.org/debian/ trixie main

# Aggiornamenti di sicurezza di testing
deb http://security.debian.org/debian-security trixie-security main
deb-src http://security.debian.org/debian-security trixie-security main

Quello mostrato è solo un esempio con i due repository principali di bookworm, 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 trixie (testing).

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 (trixie) al posto della suite (testing), che è la configurazione consigliata in presenza di una stable e verrà quindi mantenuta anche per il pinning.

apt.conf

Non si utilizza in questo caso, per non creare conflitti con il file /etc/apt/preferences. Assicurarsi perciò che /etc/apt/apt.conf non contenga una riga su Default-Release, che se presente va cancellata.

Pinning per un singolo pacchetto

Creare il file /etc/apt/preferences con questo contenuto:

Package: nomepacchetto
Pin: release n=trixie
Pin-Priority: 990

Package: *
Pin: release n=trixie
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:

$ apt-get --simulate install nomepacchetto

(e si può usare la forma abbreviata -s al posto di --simulate)

In assenza di problemi, sarà possibile installare il pacchetto "nomepacchetto" da testing semplicemente con:

# apt install nomepacchetto

In presenza di dipendenze, o si aggiungono al file preferences se non sono molte, oppure si consiglia la configurazione presentata nella sezione successiva.

Attention.png Avvertimento
Infatti mentre sarebbe possibile forzarne l'installazione con:
# apt -t trixie install nomepacchetto

c'è da considerare che l'uso dell'opzione -t 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).

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 /etc/apt/preferences come segue:

Package: *
Pin: release a=bookworm-backports
Pin-Priority: 300

Package: *
Pin: release n=trixie
Pin-Priority: 200

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

Si noti che i valori scelti non sono gli unici possibili. L'importante è che siano soddisfatte le seguenti condizioni:

  • bookworm-backports deve avere una priorità inferiore a quella di default (500), utilizzata per bookworm e bookworm-updates;
  • trixie deve avere una priorità inferiore a quella scelta per bookworm-backports;
  • trixie e bookworm-backports devono avere una priorità almeno pari a 100, per consentire gli aggiornamenti automatici una volta che un pacchetto è installato da tali repository.

Ora basterà:

# apt -t trixie install nomepacchetto

per installare nuovi pacchetti da trixie, che saranno poi aggiornati in automatico. Si noti però che perfino in questo caso gli aggiornamenti potrebbero comunque richiedere l'uso dell'opzione -t oppure il meccanismo di risoluzione dei conflitti di aptitude, se nuove dipendenze fossero aggiunte nello stesso ramo.

Testing con unstable ed experimental

La release principale sia testing, quella secondaria Sid/unstable e si utilizzino anche i repository experimental.

sources.list

deb http://deb.debian.org/debian/ testing main
deb-src http://deb.debian.org/debian/ testing main

# Aggiornamenti di sicurezza
deb http://security.debian.org/debian-security testing-security main
deb-src http://security.debian.org/debian-security testing-security main

# Unstable
deb http://deb.debian.org/debian/ sid main
deb-src http://deb.debian.org/debian/ sid main

# Experimental
deb http://deb.debian.org/debian/ experimental main
deb-src http://deb.debian.org/debian/ experimental main

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.

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.

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 /etc/apt/sources.list .

apt.conf

Assicurarsi che non sia impostata una Default-Release per non disabilitare gli aggiornamenti di sicurezza (testing-security).

Testing tipicamente non riceve comunque aggiornamenti di sicurezza da questo repository, se non quando non è possibile il porting da Sid, ma è sempre meglio tenerlo abilitato.

preferences

In questo modo entrambi i repository testing e testing-security avranno priorità maggiore di sid:

Package: *
Pin: release a=testing-security
Pin-Priority: 990

Package: *
Pin: release a=testing
Pin-Priority: 990

Si noti che questa configurazione era equivalente a impostare la Default-Release a testing nel file /etc/apt/apt.conf, prima dei cambiamenti a codename e suite dei repository di sicurezza introdotti con Debian 11 (Bullseye).

Alternativamente sarebbe possibile anche impostare una priorità inferiore per sid, purché almeno uguale a 100. Per esempio:

Package: *
Pin: release n=sid
Pin-Priority: 100

Con entrambe le configurazioni il repository di sid sarebbe equivalente a quello dei backports; ossia verrebbe consentito l'aggiornamento automatico dei pacchetti installati, ma non l'installazione automatica di nuovi pacchetti (se presenti anche in testing).

Osservazioni

  1. Usando le azioni install e upgrade senza specificare l'opzione -t sid 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.
  2. Digitando apt -t sid install vattelapesca 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 apt upgrade o apt full-upgrade continueranno a installare la versione più recente, anche prelevandola automaticamente da sid, almeno finché la versione in testing non diverrà equivalente.
  3. 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 -t/--target-release.
  4. 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 -t.
  5. 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:
    # apt -t experimental install nomepacchetto

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.

Info.png Nota
Questo esempio non permette di retrocedere automaticamente pacchetti già installati da deb-multimedia.


sources.list

Abilitiamo anche le sezioni contrib e non-free:

# Debian testing
deb http://deb.debian.org/debian/ testing main contrib non-free

# Debian testing - sicurezza
deb http://security.debian.org/debian-security testing-security main contrib non-free

# repository NON ufficiali - multimedia
deb http://www.deb-multimedia.org testing main non-free

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.

apt.conf

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

preferences

Package: *
Pin: Release o=Unofficial Multimedia Packages
Pin-Priority: 100

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.

Osservazioni

  • 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 apt.conf una release obiettivo e definendo in preferences 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 -t/--target-release in questo caso è inutile, visto che si lavora per ipotesi con una sola release.

Comandi utili

È possibile visualizzare l'elenco delle priorità relative a tutti i repository e pacchetti dichiarati con apt-cache:

$ apt-cache policy

Se si volesse visualizzare solo la priorità per un singolo singolo pacchetto, ad esempio nano, si può digitare:

$ apt-cache policy nano

Si consiglia anche l'installazione di apt-show-versions, per poter controllare velocemente da quali repository provengono i pacchetti installati sul sistema.

E per controllare se è stata impostata una Default-Release basta:

$ apt-config dump | grep -i default-release

che visualizza la riga relativa solo se presente.

Approfondimenti

Manpages

man apt.conf
man apt_preferences




Guida scritta da: Xtow Swirl-auth60.png Debianized 60%
Estesa da:
Wtf
HAL 9000
Verificata da:
Wtf
HAL 9000 15:58, 3 ago 2019 (CEST)

Verificare ed estendere la guida | Cos'è una guida Debianized