3 581
contributi
Repository & pinning: differenze tra le versioni
rimozione Default-Release da tutti gli esempi (per via del cambiamento a codename/suite dei repository di sicurezza di bullseye)
m (typo) |
(rimozione Default-Release da tutti gli esempi (per via del cambiamento a codename/suite dei repository di sicurezza di bullseye)) |
||
| Riga 33: | Riga 33: | ||
* non è stato dichiarato il parametro ''Default Release'' in un eventuale file <code>apt.conf</code>, ovvero non è stata definita una release obiettivo. | * non è stato dichiarato il parametro ''Default Release'' in un eventuale file <code>apt.conf</code>, ovvero non è stata definita una release obiettivo. | ||
Nel momento in cui l'utente esegue il comando <code>apt | 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 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. | Il problema evidentemente non può che esplodere quando si tenta di aggiornare tutti i pacchetti di sistema. | ||
| Riga 74: | Riga 74: | ||
= /etc/apt/apt.conf = | = /etc/apt/apt.conf = | ||
Questo file insieme ad altri permette di definire le opzioni di APT e relativi strumenti senza bisogno di digitarli sempre da riga di comando. Si vedano le guide dedicate ad [[apt-get]] e [[ | Questo file insieme ad altri permette di definire le opzioni di APT e relativi strumenti senza bisogno di digitarli sempre da riga di comando. Si vedano le guide dedicate ad [[apt-get]] e [[aptitude]] per dei brevi esempi contenenti alcuni dei parametri più comuni.<br/> | ||
Per quanto riguarda il pinning l'unico parametro strettamente di rilievo è: | Per quanto riguarda il pinning l'unico parametro strettamente di rilievo è: | ||
| Riga 85: | Riga 85: | ||
* 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). | * ignora tutte le impostazioni di pinning in <code>/etc/apt/preferences</code> riguardanti la stessa release e relative a tutti i pacchetti (anziché a un singolo pacchetto o a un gruppo di pacchetti). | ||
Pertanto si raccomanda di '''non''' impostare una <code>Default-Release</code> se si vuole utilizzare anche il file <code>/etc/apt/preferences</code>, per non creare conflitti tra le due configurazioni. | 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| | {{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}}''. | * 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 | * 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: | 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. | * 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. | ||
| Riga 158: | Riga 157: | ||
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>. | 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, 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>. | 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! | |||
== Stable con backports == | == Stable con backports == | ||
| Riga 331: | Riga 331: | ||
=== apt.conf === | === apt.conf === | ||
< | Assicurarsi che '''non''' sia impostata una <code>Default-Release</code> 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 === | |||
Package: * | |||
Pin: release a=testing-security | |||
Pin-Priority: 990 | |||
Package: * | |||
Pin: release a=testing | |||
Pin-Priority: 990 | |||
In questo modo entrambi i repository ''testing'' e ''testing-security'' avranno priorità maggiore di ''sid''. | |||
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]]). | |||
Alternativamente sarebbe possibile anche impostare una priorità inferiore per '''sid''', purché almeno uguale a '''100'''. Questo renderebbe il comportamento del repository di '''sid''' equivalente a quello dei [[Il Repository Backports|backports]]. Per esempio: | |||
Package: * | |||
Pin: release n=sid | |||
Pin-Priority: 300 | |||
=== Osservazioni === | === Osservazioni === | ||