3 581
contributi
Repository & pinning: differenze tra le versioni
Vai alla navigazione
Vai alla ricerca
rimosso esempio, uso di solo apt.conf/preferences in tutti gli esempi
(passaggio di versione, cambio esempi, rimozione configurazioni non legate al pinning) |
(rimosso esempio, uso di solo apt.conf/preferences in tutti gli esempi) |
||
| Riga 12: | Riga 12: | ||
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. | 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 | 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. | ||
{{Warningbox|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]].}} | {{Warningbox|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]].}} | ||
| Riga 20: | Riga 20: | ||
= Priorità come punteggio = | = 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: | 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 | * 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 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 | * 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. | * priorità '''990''' alle versioni che appartengono alla release 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 [[release]] (si supponga testing); | * 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 <code>sources.list</code>; | * 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 e stable rispettivamente); | * 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; | * 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"; | ||
| Riga 60: | Riga 60: | ||
* 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. | * 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.<br/> | 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é: | 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 priorità della stable non è sufficiente al [[downgrade]], dato che servirebbe una priorità di almeno 1000, e pertanto il repository è ignorato; | ||
| Riga 80: | Riga 80: | ||
<pre>APT::Default-Release "release_voluta";</pre> | <pre>APT::Default-Release "release_voluta";</pre> | ||
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. | che equivale alla dichiarazione in riga di comando dell'opzione '''<code>-t release_voluta</code>''' in [[apt-get]], [[apt]] e [[aptitude]]. Tale dichiarazione attribuisce priorità 990 a tutti i pacchetti appartenenti alla [[release]] specificata. | ||
{{Warningbox| | {{Warningbox| | ||
* 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 | * 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 ''jessie''. | ||
* Per quanto riguarda tutti i pacchetti della target release 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à. | * Per quanto riguarda tutti i pacchetti della target release 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à. | ||
* Questa direttiva influenza la priorità del repository principale di una release, nonché di quella relativa alla sua sicurezza, per esempio: | * Questa direttiva influenza la priorità del repository principale di una release, nonché di quella relativa alla sua sicurezza, per esempio: | ||
| Riga 91: | Riga 91: | ||
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 release_taldeitali</code> sorpassa qualunque release obiettivo ( | * 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 release_taldeitali</code> sorpassa qualunque release obiettivo (<code>Default-Release</code>) dichiarata nel file <code>apt.conf</code>. Perciò avere un pinning a 990 in preferences non è necessariamente equivalente a impostare una <code>Default-Release</code>. | ||
* Comandi del tipo <code>apt-get 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-get 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. | ||
* Definire una release obiettivo in <code>apt.conf</code> è equivalente a dichiarare in <code>preferences</code> (si veda la prossima sezione) quanto segue: | * Definire una release obiettivo in <code>apt.conf</code> è equivalente a dichiarare in <code>preferences</code> (si veda la prossima sezione) quanto segue: | ||
| Riga 154: | Riga 154: | ||
== Release pura == | == Release pura == | ||
Non serve il pinning se si usano i repository ufficiali di una sola release di Debian, ed è '''sconsigliato''' anche impostare una | Non serve il pinning se si usano i repository ufficiali 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 | 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>. | ||
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 <code>-t</code>/<code>--target-releae</code> con [[apt-get]]), salvo presenti soltanto lì, ma una volta che i pacchetti sono installati dai | 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 <code>-t</code>/<code>--target-releae</code> 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 | 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 == | == 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 dai | Si supponga di voler usare tutti i pacchetti della stable, con l'eccezione di quelli relativi a libreoffice che si vuole siano prelevati 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. È consigliabile utilizzarli soltanto per i pacchetti di cui si ha una reale necessità. | 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. È consigliabile utilizzarli soltanto per i pacchetti di cui si ha una reale necessità. | ||
| Riga 190: | Riga 190: | ||
=== apt.conf === | === apt.conf === | ||
Non serve modificarlo, né crearlo se non esiste, ed è anzi consigliabile non impostare la | Non serve modificarlo, né crearlo se non esiste, ed è anzi consigliabile non impostare la <code>Default-Release</code>. 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 === | === preferences === | ||
| Riga 201: | Riga 201: | ||
=== Osservazioni === | === Osservazioni === | ||
Per come è definito <code>preferences</code> l'installazione della versione di libreoffice da repository non | Per come è definito <code>preferences</code> l'installazione della versione di libreoffice da repository non backports è impossibile, una volta che i pacchetti entrano in tale [[repository]], anche usando l'opzione <code>-t</code> da riga di comando. | ||
Si noti che solo il pacchetto <code>libreoffice</code> e tutte le dipendenze inizianti con quello stesso prefisso possono essere installate automaticamente, per cui l'installazione o l'aggiornamento non sono garantiti in presenza di altre dipendenze da soddisfare, senza l'uso di: | |||
<pre># apt-get -t jessie-backports install libreoffice</pre> | |||
== Stable con testing == | == Stable con testing == | ||
{{Warningbox | Senza pinning ci si troverebbe con una testing effettuando gli aggiornamenti del sistema. | {{Warningbox | 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 | 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. | 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. | ||
| Riga 236: | Riga 239: | ||
</pre> | </pre> | ||
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 | 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. | Questo file è valido per tutti gli esempi di questa sezione, mentre gli altri dipendono dalla configurazione del pinning desiderata. | ||
=== Pinning per un singolo pacchetto === | === Pinning per un singolo pacchetto === | ||
Creare il file <code>/etc/apt/preferences | Creare il file <code>/etc/apt/preferences</code> con questo contenuto: | ||
<pre> | <pre> | ||
Package: nomepacchetto | Package: nomepacchetto | ||
| Riga 252: | Riga 255: | ||
</pre> | </pre> | ||
Adesso è possibile installare il pacchetto "nomepacchetto" da | Adesso è possibile installare il pacchetto "nomepacchetto" da testing con: | ||
<pre> | <pre> | ||
# apt-get install nomepacchetto | # apt-get install nomepacchetto | ||
| Riga 273: | Riga 276: | ||
=== Pinning per tutti i pacchetti di testing e backports === | === 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 | 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: | ||
<pre> | <pre> | ||
Package: * | Package: * | ||
| Riga 283: | Riga 286: | ||
Pin-Priority: 200 | Pin-Priority: 200 | ||
</pre> | </pre> | ||
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 | 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: | 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''; | * ''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à: | Ora basterà: | ||
| Riga 294: | Riga 297: | ||
# apt-get -t testing install nomepacchetto | # apt-get -t testing install nomepacchetto | ||
</pre> | </pre> | ||
per installare nuovi pacchetti da | 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 <code>-t</code>, se nuove dipendenze fossero aggiunte in testing, oppure il meccanismo di risoluzione automatica dei conflitti di [[aptitude]]. | ||
== Testing con unstable ed experimental == | == Testing con unstable ed experimental == | ||
La release principale sia [[testing]], quella secondaria [[Sid]]/[[unstable]] e si utilizzino anche i repository [[experimental]]. | La release principale sia [[testing]], quella secondaria [[Sid]]/[[unstable]] e si utilizzino anche i repository [[experimental]]. | ||
=== sources.list === | === sources.list === | ||
<pre> | <pre> | ||
deb http://ftp.it.debian.org/debian/ testing main | deb http://ftp.it.debian.org/debian/ testing main | ||
| Riga 350: | Riga 319: | ||
deb-src http://ftp.it.debian.org/debian/ experimental main | deb-src http://ftp.it.debian.org/debian/ experimental main | ||
</pre> | </pre> | ||
Di default tutti hanno priorità 500, a eccezione di | 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 <code>/etc/apt/sources.list</code> . | |||
=== apt.conf === | === apt.conf === | ||
| Riga 359: | Riga 331: | ||
</pre> | </pre> | ||
Questa configurazione assegna al repository principale e a quello di sicurezza di testing un pinning di 990. Di conseguenza | 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 === | === preferences === | ||
| Riga 365: | Riga 337: | ||
=== Osservazioni === | === 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-get -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-get upgrade</code> o <code>apt-get dist-upgrade</code> continueranno a installare la versione più recente, anche prelevandola automaticamente da sid, almeno finché la versione in testing non diverrà equivalente. | |||
Questo comportamento è del tutto voluto, perché sarebbe troppo pericoloso aggiornare senza supervisione ciò che proviene da | # 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>. | ||
# apt-get -t experimental install nomepacchetto | # 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-get -t experimental install nomepacchetto</code> | ||
</ | |||
== Testing con pacchetti non-free e repository deb-multimedia == | == Testing con pacchetti non-free e repository deb-multimedia == | ||
| Riga 393: | Riga 364: | ||
=== apt.conf === | === apt.conf === | ||
Non è necessaria nessuna modifica. Sarebbe inoltre del tutto inutile impostare una | 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. | ||
=== preferences === | === preferences === | ||
| Riga 406: | Riga 377: | ||
=== Osservazioni === | === 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 <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. | * 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. | ||
* L'utilizzo dell'opzione | * 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. | ||
= Comandi utili = | = Comandi utili = | ||
| Riga 414: | Riga 385: | ||
Se si volesse visualizzare solo la priorità per un singolo singolo pacchetto, ad esempio nano, si può digitare: | Se si volesse visualizzare solo la priorità per un singolo singolo pacchetto, ad esempio nano, si può digitare: | ||
<pre>$ apt-cache policy nano</pre> | <pre>$ apt-cache policy nano</pre> | ||
E per controllare se è stata impostata una <code>Default-Release</code> basta: | |||
<pre>$ apt-config dump | grep -i "^APT::Default-Release"</pre> | |||
che visualizza la riga relativa solo se presente. | |||
= Approfondimenti = | = Approfondimenti = | ||
| Riga 427: | Riga 402: | ||
|Verificata_da = | |Verificata_da = | ||
: [[Utente:Wtf|Wtf]] | : [[Utente:Wtf|Wtf]] | ||
: [[Utente:HAL 9000|HAL 9000]] | : [[Utente:HAL 9000|HAL 9000]] 10:46, 10 mag 2015 (CEST) | ||
|Numero_revisori = 2 | |Numero_revisori = 2 | ||
}} | }} | ||
[[Categoria:Apt]][[Categoria:E-zine]][[Categoria:Repository ufficiali]] | [[Categoria:Apt]][[Categoria:E-zine]][[Categoria:Repository ufficiali]] | ||