Repository & pinning: differenze tra le versioni

Vai alla navigazione Vai alla ricerca

Repository & pinning (visualizza wikitesto)

Versione delle 11:39, 24 giu 2014

2 593 byte rimossi ,  24 giu 2014
riformulazioni delle frasi per rientrare sotto i 30 KB, tagliando il meno possibile
(estensione (TODO: da ridurre qualcosa per rientrare sotto 32KB...))
(riformulazioni delle frasi per rientrare sotto i 30 KB, tagliando il meno possibile)
Riga 14: Riga 14:
# Debian testing, attualmente ''Jessie'';
# Debian testing, attualmente ''Jessie'';
# Debian unstable, attualmente (e sempre,  un nome fisso) ''Sid''.
# Debian unstable, attualmente (e sempre,  un nome fisso) ''Sid''.
Il software della stable non viene aggiornato, eccezion fatta per gli aggiornamenti della sicurezza; il software della testing e della unstable viene al contrario aggiornato frequentemente, con una maggiore frequenza per la unstable. Oltre queste tre, ci sarebbero anche la ''oldstable'' (la vecchia stable, precedente all’attuale stable) e la ''experimental'' che non è una versione completa e funzionante di Debian, ma solo un repository contenente vario software in fase di progettazione, da sperimentare o altamente instabile, dal quale si può attingere dalle altre versioni ma a proprio rischio.
Il software della stable non viene aggiornato, eccezion fatta per gli aggiornamenti di sicurezza; contrariamente a quello della testing e ancor più della unstable. Oltre a queste tre, ci sono anche la ''oldstable'', la versione precedente della stable, e la ''experimental'', che non è una versione completa e funzionante di Debian, ma solo un repository contenente software in fase di progettazione, da sperimentare o altamente instabile.


Spesso accade che utilizzando la testing o ancor di più la stable si voglia del software più nuovo rispetto a quello in dotazione; o che al contrario, utilizzando la testing o ancor di più la unstable si voglia del software più stabile rispetto a quello in dotazione. Qui entra in gioco il pinning dei repository, o meglio “tra i repository”, che permette di installare con semplicità del software appartenente a una distribuzione di Debian diversa da quella in uso o anche solo appartenente alla stessa distribuzione, ma proveniente da un altro repository.Tutto ciò riducendo al minimo (posto di sapere quel che si fa) il rischio di creare problemi nel sistema e nel gestore dei pacchetti.
Se si vuole software più aggiornato, la via consigliata è l'uso dei ''backports'' ufficiali, ma può accadere che non tutti gli aggiornamenti siano presenti. Qui entra in gioco il pinning, che permette di installare software appartenente a più release.


{{Warningbox|Installare pacchetti provenienti da distribuzioni e/o fonti differenti è sempre e comunque fonte di possibili rischi, anche se piccoli. Questa guida presuppone che il lettore abbia ben chiari i concetti esposti nella guida [[I repository ed il loro utilizzo]], nonché di avere discreta conoscenza di strumenti come [[apt-get]] e [[aptitude]].}}
{{Warningbox|Installare pacchetti provenienti da distribuzioni e/o fonti differenti è sempre e comunque fonte di rischi, ed è sconsigliato. Questa guida presuppone la comprensione dei concetti esposti nella guida [[I repository ed il loro utilizzo]], nonché la conoscenza di [[apt-get]] o [[aptitude]].}}


Prima di procedere nella descrizione operativa del pinning è '''fondamentale''' capire come gestisce la priorità dei pacchetti APT e sapere che:
Prima di procedere nella descrizione operativa del pinning è '''fondamentale''' capire come gestisce la priorità dei pacchetti APT e sapere che:
* Col termine distribuzione si intendono stable, testing e unstable. Ciascuna distribuzione ha un suo singolo repository (fonte) principale (due se si conteggia anche l'eventuale repository dedicato agli aggiornamenti di sicurezza) che è quello automaticamente dichiarato dall'installer di debian, ma si tenga presente che ogni distribuzione può avere più fonti sia ufficiali che non ufficiali.
* Con "distribuzione" si intendono stable, testing e unstable. Ciascuna ha un singolo repository (fonte) principale (due con il repository dedicato agli aggiornamenti di sicurezza, mancante per la unstable) che è quello automaticamente dichiarato dall'installer di debian, ma ogni distribuzione può avere più fonti, ufficiali e non.
* Col termine fonti si intendono genericamente i repository, ufficiali (es. stable, testing, unstable e backports) o meno (es. deb-multimedia), che forniscono pacchetti relativi ad una o più distribuzioni. Ogni fonte può avere più copie di se stesso (mirrors).
* Con "fonti" si intendono i repository, ufficiali e non, che forniscono pacchetti relativi ad una o più distribuzioni. Ogni fonte può avere più copie di se stesso (mirrors).
{{Box|Importante|Il pinning è uno strumento per regolare la priorità in base al numero di versione dei pacchetti, e non alla fonte di provenienza. Questo significa che non è possibile discriminare tra due pacchetti aventi lo stesso numero di versione e provenienti da due repository differenti, ovvero in caso di pari versione ad essere installato sarà la versione proveniente dal repository elencato per primo nel file <code>sources.list</code>.}}
{{Box|Importante|Il pinning è uno strumento per regolare la priorità in base al numero di versione dei pacchetti, e non alla fonte di provenienza. Non è possibile discriminare tra pacchetti aventi la stessa versione e provenienti da più repository, ovvero ad essere installato sarà quello proveniente dal repository elencato per primo nel file <code>sources.list</code>.}}


= Priorità come punteggio =
= Priorità come punteggio =


Il concetto di priorità viene gestito attraverso l'assegnazione di un punteggio ai vari pacchetti, sia installati che ancora da installare. Valgono le seguenti regole:
La priorità viene gestita attraverso l'assegnazione di un punteggio ai vari pacchetti, sia installati che ancora da installare. Valgono le seguenti regole:


* priorità '''1''', caso particolare e poco comune. È quella di default per ''experimental'' ('''NotAutomatic: yes''' nel file ''Release'' del repository). Si veda il manuale (<code>man apt_preferences</code>) per maggiori informazioni.
* priorità '''1''', caso particolare e poco comune. È quella di default per ''experimental'' ('''NotAutomatic: yes''' nel file ''Release'' del repository). Si veda il manuale per maggiori informazioni.
* priorità '''100''' alla versione dei pacchetti già installati e quella dei backports ufficiali ('''NotAutomatic: yes''' e '''ButAutomaticUpgrades: yes''' nel file ''Release'' del repository).
* priorità '''100''' alla versione dei pacchetti già installati e quella dei backports ufficiali ('''NotAutomatic: yes''' e '''ButAutomaticUpgrades: yes''' nel file ''Release'' del repository).
* priorità '''500''' alle versioni che non appartengono alla distribuzione obiettivo, dove con quest'ultimo termine si deve intendere "Default Release", "Target Release". Si noti che di default non esiste una "Default Release", e quindi ogni repository ha una priorità di 500, salvo ''backports'' ed ''experimental''.
* priorità '''500''' alle versioni che non appartengono alla distribuzione obiettivo, dove con quest'ultimo termine si deve intendere "Default Release", "Target Release". Di default non è impostata una "Default Release", e quindi ogni repository a parte ''backports'' ed ''experimental'' ha una priorità di 500.
* priorità '''990''' alle versioni che non sono installate e appartengono alla distribuzione obiettivo, posto che l'utente abbia definito una distribuzione obiettivo, altrimenti la priorità assegnata sarà una di quelle appena descritte.
* priorità '''990''' alle versioni che appartengono alla distribuzione obiettivo, posto che sia definita.


Piccolo esempio teorico. Si supponga quanto segue:
Piccolo esempio teorico. Si supponga quanto segue:
* si desidera installare il pacchetto "vattelapesca" appartenente alla propria distribuzione, cioè quella che si è installata (si supponga testing);
* si desidera installare il pacchetto "vattelapesca" appartenente alla propria distribuzione (si supponga testing);
* il suddetto pacchetto è presente in tre fonti, repoA, repoB, repoC tutte correttamente specificante nel file <code>source.list</code>;
* il suddetto pacchetto è presente in tre fonti: repoA, repoB, repoC; tutte correttamente specificante nel file <code>source.list</code>;
* tutti i pacchetti presenti in repoA appartengono alla distribuzione installata, in repoB e repoC sono contenuti pacchetti appartenenti ad un'altra distribuzione (ad esempio unstable e stable rispettivamente);
* tutti i pacchetti presenti in repoA appartengono alla distribuzione installata, in repoB e repoC sono contenuti pacchetti appartenenti ad un'altra distribuzione (ad esempio unstable e stable rispettivamente);
* la versione di "vattelapesca" in repoA è la 1.4, in repoB la 2.0 e in in repoC la 1.1;
* la versione di "vattelapesca" in repoA è la 1.4, in repoB la 2.0 e in in repoC la 1.1;
* nel sistema è installata la versione 1.3 di "vattelapesca";
* nel sistema è installata la versione 1.3 di "vattelapesca";
* non esiste un file <code>preferences</code> o comunque non è stata specificata una priorità per nessuna delle tre distribuzioni considerate;
* non esiste un file <code>preferences</code> o comunque non è stata specificata una priorità per nessuna delle tre distribuzioni considerate;
* non è stato dichiarato il parametro ''Default Release'' in un eventuale file <code>apt.conf</code>, ovvero non è stata esplicitamente definita una distribuzione obiettivo.
* non è stato dichiarato il parametro ''Default Release'' in un eventuale file <code>apt.conf</code>, ovvero non è stata definita una distribuzione obiettivo.


Nel momento in cui l'utente esegue il comando <code>apt-get install vattelapesca</code> saranno assegnati i seguenti punteggi:
Nel momento in cui l'utente esegue il comando <code>apt-get install vattelapesca</code> sarà assegnata una priorità di 500 ai "vattelapesca" di repoA, repoB e repoC.<br/>
* 500 a "vattelapesca" presente in 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.
* 500 a "vattelapesca" presente in repoB;
Il problema evidentemente non può che esplodere quando si tenta di aggiornare tutti i pacchetti di sistema.
* 500 a "vattelapesca" presente in repoA;
Tutti e tre i pacchetti hanno lo stesso punteggio, ma il pacchetto proveniente da C viene immediatamente scartato perché implicherebbe retrocessione dello stesso (downgrade, il significato delle varie fascie di punteggio sarà spiegato poco più avanti). A questo punto APT sceglierà tra repoA e repoB in base ad un altro criterio, la versione, quindi ad essere installato sarà il pacchetto proveniente da repoB e non da repoA come desiderato.
Il problema evidentemente non può che esplodere quando si esegue il comando <code>apt-get upgrade</code> (o peggio <code>apt-get dist-upgrade</code>), cioè quando si tenta di aggiornare tutti i pacchetti di sistema.


La soluzione è, come facilmente intuibile, quella di assegnare manualmente un punteggio ai vari pacchetti, singolarmente o raggruppandoli. Prima però è necessario capire il significato dei vari punteggi (pin-priority). Nel seguito si indicherà col termine "candidato" il pacchetto o gruppo di pacchetti proveniente dalla generica fonte dichiarata nel file <code>sources.list</code>.
La soluzione è quella di assegnare manualmente un punteggio ai vari pacchetti, singolarmente o raggruppandoli. Prima però è necessario capire il significato dei vari punteggi (''Pin-Priority''). Nel seguito si indicherà col termine "candidato" il pacchetto o gruppo di pacchetti proveniente dalla generica fonte dichiarata nel file <code>sources.list</code>.


* Pin '''minore di 0''' (negativo), l’installazione del candidato è impedita a priori (salvo apposito comando).
* 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 le seguenti due condizioni: primo non esistono candidati appartenenti ad altre distribuzioni, secondo nel sistema non è già installata una versione (anche inferiore) del candidato.
* Pin compreso tra '''1 e 99''', il candidato sarà installato solo se sono verificate entrambe queste condizioni: non esistono candidati appartenenti ad altre distribuzioni, e nel sistema non è già installata una versione (anche inferiore) del candidato.
* Pin compreso tra '''100 e 499''', il candidato sarà installato solo se non esistono candidati appartenenti ad altre distribuzioni e se la versione eventualmente già installata non è superiore a quella del candidato.
* Pin compreso tra '''100 e 499''', il candidato sarà installato solo se non esistono candidati appartenenti ad altre distribuzioni e se la versione eventualmente già installata non è superiore.
* Pin compreso tra '''500 e 989''', il candidato sarà installato solo se non esistono candidati appartenenti alla distribuzione obiettivo e se la versione eventualmente già installata non è superiore a quella del candidato. Si noti che il semplice fatto di aver installato una certa distribuzione, per esempio testing, non significa aver definito la distribuzione obiettivo, che può essere solo definita manualmente dall'utente (il come sarà spiegato nella discussione del file <code>apt.conf</code>).
* Pin compreso tra '''500 e 989''', il candidato sarà installato solo se non esistono candidati appartenenti alla distribuzione obiettivo e se la versione eventualmente già installata non è superiore a quella del candidato. Si noti che il semplice fatto di aver installato una certa distribuzione, per esempio testing, non significa aver definito la distribuzione obiettivo, che può essere solo definita manualmente dall'utente (il come sarà spiegato nella discussione del file <code>apt.conf</code>).
* 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 a quella del candidato.
* 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, è quindi possibile la retrocessione di versione (downgrade) se la versione eventualmente già installata è superiore a quella del candidato. Es. è possibile installare la versione 1.1 di un pacchetto anche se ad essere già installata è la 1.2 o 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.}}
{{Box|IMPORTANTE|Si noti che gli intervalli sopra specificati sono la diretta conseguenza della procedura di assegnamento automatico di APT.}}
Posto infatti 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 ovviamente di aver specificato tutti e tre i repository in <code>sources.list</code>) è evidente che un candidato vattelapesca di stable potrà essere installato solo se:
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 due fonti, infatti APT assegnerebbe automaticamente a tali candidati una priorità di 500 (500 > 44).
# Non esistono altri candidati dello stesso pacchetto provenienti dalle altre fonti, infatti APT assegnerebbe a loro automaticamente una priorità di 500 (500 > 44).
# Nessun candidato di "vattelapesca" è mai stato installato, infatti se così non fosse alla versione già installata di "vattelapesca" sarebbe assegnata in automatico una priorità di 100 (100 > 44), a prescindere dalla versione del pacchetto installato, ovvero anche quando la versione installata fosse inferiore a quella del nuovo candidato di stable disponibile.
# Nessun candidato di "vattelapesca" è mai stato installato, infatti alla versione installata di "vattelapesca" sarebbe assegnata una priorità di 100 (100 > 44), a prescindere dalla sua versione, ovvero anche quando questa fosse inferiore a quella del nuovo candidato di stable disponibile.


{{Box|Nota|
{{Box|Nota|* APT può derogare alle regole generali sopra esposte in casi particolari per soddisfare le varie dipendenze dei pacchetti.}}
* Gli intervalli sopra citati sono presi tali e quali dal manuale di ''apt_preferences'', tuttavia a volte si è osservato che i limiti funzionano come dovrebbero se traslati in alto di una unità, ad esempio l'ultimo intervallo potrebbe partire da 1001 invece che da 1000.
* APT può derogare alle regole generali sopra esposte in casi particolari per soddisfare le varie dipendenze dei pacchetti.}}


== Priorità come punteggio in caso di aggiornamento ==
== Priorità in caso di aggiornamento ==


Se una versione di un pacchetto è già installata sul sistema, la lettura dei punteggi può portare a un'errata interpretazione delle priorità. In particolare:
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à a partire da 1000, il che significa che tutti i repository con priorità minore di 1000 sono ignorati, se la loro versione è inferiore a quella attualmente installata;
* il downgrade è possibile solo con una priorità almeno pari a 1000, il che significa che tutti i repository con una versione inferiore e priorità minore di 1000 sono ignorati;
* i pacchetti installati hanno priorità 100, il che significa che un pacchetto può essere aggiornato automaticamente se esiste almeno un repository con una versione più recente e priorità almeno 100.
* i pacchetti installati hanno priorità 100, e quindi un pacchetto può essere aggiornato automaticamente se esiste un repository con una versione più recente con una priorità almeno uguale.


Supponiamo che si assegni priorità 990 alla stable. I backports di default ne hanno una di 100. Ciò significa che non si può installare (automaticamente) una versione di un pacchetto che si trovi in entrambi i repository.<br/>
Per esempio la stable di default ha priorità 500, 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 (che assegna priorità temporanea di 990), quel pacchetto verrà aggiornato automaticamente quando saranno disponibili nuovi aggiornamenti, perché la priorità della stable non è sufficiente al downgrade e pertanto il repository è ignorato, mentre d'altra parte la versione dei backports è più recente e la priorità (di default) è almeno pari a quella locale, che è sempre di 100.
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 e pertanto il repository è ignorato, mentre d'altra parte la versione dei backports è più recente e la loro priorità è almeno pari a quella locale.


= /etc/apt/apt.conf =
= /etc/apt/apt.conf =
Riga 95: Riga 90:


Si noti inoltre che:
Si noti inoltre che:
* Le dichiarazioni di parametri da riga di comando hanno sempre la precedenza su quelli definiti in un file di configurazione, quindi usare un comando del tipo <code>apt-get install pacchetto -t distribuzione_taldeitali</code> sorpassa qualunque distribuzione obiettivo (''Default-Release'') dichiarata nel file <code>apt.conf</code>. Quindi avere un pinning a 990 in preferences non è necessariamente equivalente a impostare una ''Default-Release''.
* Le dichiarazioni di parametri da riga di comando hanno sempre la precedenza su quelli definiti in un file di configurazione, quindi usare un comando del tipo <code>apt-get install pacchetto -t distribuzione_taldeitali</code> sorpassa qualunque distribuzione obiettivo (''Default-Release'') dichiarata nel file <code>apt.conf</code>. Perciò avere un pinning a 990 in preferences non è necessariamente equivalente a impostare una ''Default-Release''.
* Comandi del tipo <code>apt-get install pacchetto/distribuzione_taldeitali</code> non cambiano la ''target release'', ma si limitano a dire di prelevare lo specifico pacchetto dalla distribuzione indicata invece che da quella predefinita. Questo implica che le dipendenze continueranno ad essere risolte in base alla distribuzione obiettivo eventualmente specificata in <code>apt.conf</code> e/o in base al file preferences e/o in accordo all'algoritmo predefinito.
* Comandi del tipo <code>apt-get install pacchetto/distribuzione_taldeitali</code> non cambiano la ''target release'', ma si limitano a dire di prelevare lo specifico pacchetto dalla distribuzione indicata invece che da quella predefinita. Questo implica che le dipendenze continueranno ad essere risolte in base alla distribuzione obiettivo eventualmente specificata in <code>apt.conf</code> e/o in base al file preferences e/o in accordo all'algoritmo predefinito.
* Definire una distribuzione obiettivo in <code>apt.conf</code> è equivalente a dichiarare in <code>preferences</code> (si veda la prossima sezione) quanto segue
* Definire una distribuzione obiettivo in <code>apt.conf</code> è equivalente a dichiarare in <code>preferences</code> (si veda la prossima sezione) quanto segue
Riga 149: Riga 144:
== Blocco/retrocessione di pacchetti ==
== Blocco/retrocessione di pacchetti ==


Il file <code>preferences</code> come già accennato 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 di 1000 per il pacchetto desiderato. Se per esempio nel file <code>preferences</code> fosse presente un record come il seguente:
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:


<pre>
<pre>
Riga 160: Riga 155:
# 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 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.
# 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 o ridurre il pin sotto 1000 o eliminare del tutto il record.
Per permettere nuovamente l'aggiornamento del pacchetto è necessario eliminare il record.


=== Retrocedere l'intero sistema ===
=== Retrocedere l'intero sistema ===


Nella maggior parte dei casi (o forse sempre) questa '''È UNA FOLLIA''', tuttavia per motivazioni puramente didattiche si mostra come fare. In primis è necessario eliminare, se presente, dal file <code>apt.conf</code> il parametro ''default-release'', dopo di che aggiungere al file <code>preferences</code> un record come il seguente (sostituire a "stable" la versione desiderata, ad esempio "testing" se si vuole retrocedere da "unstable").
Nella maggior parte dei casi (o forse sempre) questa '''È UNA FOLLIA''', tuttavia per motivazioni didattiche si mostra come fare. In primis è necessario eliminare, se presente, dal file <code>apt.conf</code> il parametro ''default-release'', dopo di che aggiungere al file <code>preferences</code> un record come il seguente (sostituire a "stable" la versione desiderata, ad esempio "testing" se si vuole retrocedere da "unstable").
<pre>
<pre>
Package: *
Package: *
Riga 181: Riga 176:
== Release pura ==
== Release pura ==


Sebbene non sia necessario definire il pinning nel caso ci si limiti ad usare i repository ufficiali della propria release di debian, può comunque essere prudente definire un file <code>apt.conf</code>. Se infatti si dovesse decidere di aggiungere altri repository in seguito non si rischierebbe il disastro nel caso in cui ci si dimenticasse di definire correttamente un pinning.
Non serve il pinning se si usano i repository ufficiali di una sola release di Debian, ma può essere prudente definire un file <code>apt.conf</code> se si dovessero aggiungere altri repository in seguito e ci si dimenticasse di definire correttamente un pinning.


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


Allo stesso modo in una release pura i pacchetti dei ''backports'' continuano a restare disabilitati per la loro prima installazione, salvo presenti soltanto nei ''backports'' o li si scelga manualmente come target release, ma i pacchetti installati dai ''backports'' vengono aggiornati automaticamente senza bisogno di pinning. Il che corrisponde al loro comportamento di default anche in assenza di una ''Default-Release'', per cui non c'è bisogno di cambiarlo.
In una release pura i pacchetti dei ''backports'' continuano a restare disabilitati per la loro prima installazione, salvo presenti soltanto lì o li si scelga come target release, ma i pacchetti installati dai ''backports'' vengono aggiornati automaticamente senza bisogno di pinning. Il che corrisponde al loro comportamento di default anche in assenza di una ''Default-Release''.


=== sources.list ===
=== sources.list ===
Riga 223: Riga 218:
== Stable con backports ==
== Stable con backports ==


Si supponga di voler usare tutti i pacchetti della stable, con l'eccezione di quelli relativi a libre office e iceweasel.
Si supponga di voler usare tutti i pacchetti della stable, con l'eccezione di quelli relativi a libreoffice e iceweasel.


=== sources.list ===
=== sources.list ===
HAL 9000
3 581

contributi

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

Menu di navigazione