Repository & pinning
 |
|
 |
 Versioni Compatibili Tutte le versioni supportate di Debian |
 |
Questa guida è basata sui seguenti articoli presenti all'interno del numero 2 dell'e-zine di Debianizzati.org : |
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.
|
ATTENZIONE Installare pacchetti provenienti da release differenti è sempre e comunque fonte di rischi, ed è sconsigliato. Questa guida presuppone la comprensione dei concetti esposti nella guida I repository ed il loro utilizzo, nonché la conoscenza di apt-get. |
|
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
preferenceso 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-get 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.
|
|
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:
- 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.
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.
|
|
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 in apt-get, apt e aptitude. Tale dichiarazione attribuisce priorità 990 a tutti i pacchetti appartenenti alla release specificata.
|
|
ATTENZIONE
|
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
apt-get install pacchetto -t release_taldeitalisorpassa qualunque release obiettivo (Default-Release) dichiarata nel fileapt.conf. Perciò avere un pinning a 990 in preferences non è necessariamente equivalente a impostare unaDefault-Release. - Comandi del tipo
apt-get install pacchetto/release_taldeitalinon 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 inapt.confe/o in base al filepreferencese/o in accordo all'algoritmo predefinito. - Definire una release obiettivo in
apt.confè equivalente a dichiarare inpreferences(si veda la prossima sezione) quanto segue:
Package: * Pin: release a=release_voluta Pin-Priority: 990
|
|
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. La sintassi generale è la seguente:
Package: nome pacchetto o espressione regolare Pin: parametro da usare per identificare la versione desiderata Pin-Priority: numero
Un paio di esempi del tutto arbitrari:
Package: vlc Pin: release a=testing Pin-Priority: 991 Package: virtualbox4* Pin: Release o=Oracle Corporation Pin-Priority: 780
Nel primo esempio si è definito il pinning per il pacchetto di nome "vlc", richiedendo che le versioni appartenenti alla release testing abbiano priorità 991. Nel secondo invece sfruttando una semplicissima espressione regolare si impone che tutti i pacchetti il cui nome inizia per "virtualbox4" e appartenenti al repository la cui origine è definita come "Oracle Corporation" abbiano priorità 780.
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:
|
|
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. |
|
Suggerimento Specificare nel file sources.list sempre per primi il o i repository principali della release obiettivo.
|
|
|
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:
- 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.
Per maggiori informazioni si consulti la guida Fare il downgrade di uno o più pacchetti.
|
|
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
Release pura
Non serve il pinning se si usano i repository ufficiali 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, 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.
Si ricorda nuovamente che in una release pura non serve il pinning nemmeno per i backports, perché i pacchetti contenuti non sono mai installati automaticamente senza specificare una release obiettivo (opzione -t/--target-releae con apt-get), salvo presenti soltanto lì, ma una volta che i pacchetti sono installati dai backports verranno aggiornati automaticamente.
Inoltre anche nel caso che si utilizzino soltanto i repository sid ed experimental non sarebbe 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.
Stable con backports obbligati
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.
Questo esempio non è consigliato, ma intende soltanto mostrare alcune delle problematiche nella configurazione del pinning, quando si applica solo a una selezione ristretta di pacchetti.
|
|
ATTENZIONE Si noti infatti che mentre è possibile impedire l'installazione dei pacchetti dalla stable quando presenti anche nei backports, non è possibile garantirne l'installazione automatica dei pacchetti dai backports. Questo perché, per soddisfare tutte le possibili dipendenze dei pacchetti installati, l'unico modo sarebbe assegnare un pinning di almeno 500 a tutti i pacchetti provenienti dai backports. Si ricorda però 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à. |
sources.list
deb http://ftp.it.debian.org/debian/ jessie main deb-src http://ftp.it.debian.org/debian/ jessie main # Aggiornamenti di sicurezza deb http://security.debian.org/ jessie/updates main deb-src http://security.debian.org/ jessie/updates main # Aggiornamenti raccomandati deb http://ftp.it.debian.org/debian/ jessie-updates main deb-src http://ftp.it.debian.org/debian/ jessie-updates main # Backports deb http://ftp.it.debian.org/debian/ jessie-backports main deb-src http://ftp.it.debian.org/debian/ jessie-backports main
Quello mostrato è solo un esempio con: i due repository principali di Jessie, quello normale e di sicurezza; gli aggiornamenti raccomandati, che non sono strettamente necessari; e i backports.
Di default si ricordi che tutti i repository hanno una priorità di 500, a eccezione di jessie-backports che ne hanno una di 100.
apt.conf
Non serve modificarlo, né crearlo se non esiste, ed è anzi consigliabile non impostare la Default-Release. Si noti infatti che il suo utilizzo per jessie non avrebbe effetto sugli aggiornamenti raccomandati (jessie-updates), che verrebbero quindi disabilitati come i backports.
preferences
Package: libreoffice* Pin: release n=jessie-backports Pin-Priority: 990
Osservazioni
Per come è definito preferences l'installazione della versione di libreoffice da repository non backports è impossibile, una volta che i pacchetti entrano in tale repository, anche usando l'opzione -t da riga di comando.
Si noti che solo il pacchetto libreoffice e tutte le dipendenze inizianti con quello stesso prefisso possono essere installate automaticamente dai backports, per cui l'installazione o l'aggiornamento non sono garantiti in presenza di altre dipendenze da soddisfare dallo stesso ramo senza l'uso di:
# apt-get -t jessie-backports install libreoffice
Questo è il motivo per cui si sconsiglia l'uso del pinning per i backports, visto che basta utilizzare direttamente questo comando, senza modificare le impostazioni del sistema.
Stable con testing
|
|
ATTENZIONE 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
deb http://ftp.it.debian.org/debian/ jessie main deb-src http://ftp.it.debian.org/debian/ jessie main # Aggiornamenti di sicurezza deb http://security.debian.org/ jessie/updates main deb-src http://security.debian.org/ jessie/updates main # Aggiornamenti raccomandati deb http://ftp.it.debian.org/debian/ jessie-updates main deb-src http://ftp.it.debian.org/debian/ jessie-updates main # Backports deb http://ftp.it.debian.org/debian/ jessie-backports main deb-src http://ftp.it.debian.org/debian/ jessie-backports main # Testing deb http://ftp.it.debian.org/debian/ stretch main deb-src http://ftp.it.debian.org/debian/ stretch main # Aggiornamenti di sicurezza di testing deb http://security.debian.org/ stretch/updates main deb-src http://security.debian.org/ stretch/updates main
Quello mostrato è solo un esempio con i due repository principali di Jessie, 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 Stretch (testing).
Questo file è valido per tutti gli esempi di questa sezione, mentre gli altri dipendono dalla configurazione del pinning desiderata.
Pinning per un singolo pacchetto
Creare il file /etc/apt/preferences con questo contenuto:
Package: nomepacchetto Pin: release a=testing Pin-Priority: 990 Package: * Pin: release a=testing Pin-Priority: -1
Adesso è possibile installare il pacchetto "nomepacchetto" da testing con:
# apt-get install nomepacchetto
oppure in caso di dipendenze con:
# apt-get -t testing install nomepacchetto
Con questo secondo comando è superfluo l'uso del pinning per "nomepacchetto", se non per ricordarsi la configurazione desiderata.
|
|
Aptitude È possibile anche installare il pacchetto tramite aptitude: # aptitude install nomepaccheto facendo risolvere a questo comando il conflitto causato dal pinning del pacchetto e le sue dipendenze, fino ad ottenere la soluzione desiderata. Si presti però attenzione alle soluzioni proposte, prima di accettarle. Questo metodo non è consigliato, ma è presentato per completezza per chiarire come in alcuni casi è possibile l'installazione di un pacchetto senza specificare manualmente l'opzione |
Si noti anche che non si avranno aggiornamenti automatici per i pacchetti che vengono installati con questo metodo, a meno che riguardino soltanto quel singolo pacchetto e nessun altro. In caso contrario bisogna rieseguire il precedente comando, avvalersi di aptitude per risolvere i conflitti, oppure impostare il pinning con la configurazione trattata in seguito.
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=jessie-backports Pin-Priority: 300 Package: * Pin: release a=testing Pin-Priority: 200
Dove jessie-backports è il nome della suite (e il codename, che sono uguali per i backports) dei repository backports di Jessie. È consigliabile specificare la nuova priorità a prescindere dalla loro presenza, altrimenti se attivati saranno sempre nascosti da testing, 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:
- jessie-backports deve avere una priorità inferiore a quella di default (500), utilizzata per jessie e jessie-updates;
- testing deve avere una priorità inferiore a quella scelta per jessie-backports;
- testing e jessie-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-get -t testing install nomepacchetto
per installare nuovi pacchetti da testing, che saranno poi aggiornati in automatico. Si noti però che perfino in questo caso gli aggiornamenti potrebbero comunque richiedere l'uso dell'opzione -t, se nuove dipendenze fossero aggiunte in testing, oppure il meccanismo di risoluzione automatica dei conflitti di aptitude.
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://ftp.it.debian.org/debian/ testing main deb-src http://ftp.it.debian.org/debian/ testing main # Aggiornamenti di sicurezza deb http://security.debian.org/ testing/updates main deb-src http://security.debian.org/ testing/updates main # Unstable deb http://ftp.it.debian.org/debian/ sid main deb-src http://ftp.it.debian.org/debian/ sid main # Experimental deb http://ftp.it.debian.org/debian/ experimental main deb-src http://ftp.it.debian.org/debian/ experimental main
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
APT::Default-Release "testing";
Questa configurazione assegna al repository principale e a quello di sicurezza di testing un pinning di 990. Di conseguenza sid resta a 500 ed experimental a 1.
preferences
Non è necessario configurare alcun pinning, perché è sufficiente l'uso di Default-Release nel file apt.conf.
Osservazioni
- Usando le azioni install e upgrade senza specificare l'opzione
-t sidsi 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
apt-get -t sid install vattelapescasi installerà la versione "vattelapesca" appartenente ad sid, così come le sue dipendenze. Si noti che dopo l'avvenuta installazione, successivi aggiornamenti tramite comandi del tipoapt-get upgradeoapt-get dist-upgradecontinueranno 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
-t/--target-release. - 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. - 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-get -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.
|
|
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://ftp.it.debian.org/debian/ testing main contrib non-free ### Debian testing - sicurezza deb http://security.debian.org/ testing/updates 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.confuna release obiettivo e definendo inpreferencesprima 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-releasein 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
E per controllare se è stata impostata una Default-Release basta:
$ apt-config dump | grep -i "^APT::Default-Release"
che visualizza la riga relativa solo se presente.
Approfondimenti
Manpages
man apt.conf
man apt_preferences
| Guida scritta da: Xtow |  Debianized 60%
|
| Estesa da: | |
| Verificata da: | |
|
Verificare ed estendere la guida | Cos'è una guida Debianized | |