Repository & pinning: differenze tra le versioni

Vai alla navigazione Vai alla ricerca
passaggio di versione, cambio esempi, rimozione configurazioni non legate al pinning
mNessun oggetto della modifica
(passaggio di versione, cambio esempi, rimozione configurazioni non legate al pinning)
Riga 54: Riga 54:
# Non esistono altri candidati dello stesso pacchetto provenienti dalle altre fonti, infatti APT assegnerebbe a loro automaticamente 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 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.
# 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|* APT può derogare alle regole generali sopra esposte in casi particolari per soddisfare le varie dipendenze dei pacchetti.}}


== Priorità in caso di aggiornamento ==
== Priorità in caso di aggiornamento ==
Riga 68: Riga 66:


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]].
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.
{{Box|Nota|Alcuni programmi della suite APT possono derogare alle regole generali per soddisfare le varie dipendenze dei pacchetti. Per esempio è il caso di [[aptitude]], che è in grado di proporre risoluzioni automatiche dei conflitti, consentendo anche di ignorare il pinning.}}


= /etc/apt/apt.conf =
= /etc/apt/apt.conf =
Riga 75: 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''' sia in [[apt-get]] che [[Aptitude]]. Tale dichiarazione attribuisce priorità 990 a tutti i pacchetti appartenenti alla [[release]] specificata.
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.


{{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 ''stable'' e ''wheezy''. Per esempio ''backports'' non comporta problemi poiché i precedenti due parametri valgono ''nome_suite-backports'' e ''nome_codename-backports'', viceversa quello di ''deb-multimedia'' usa gli stessi identici valori di quelli principali.
* 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 esempio ''backports'' non comporta problemi poiché i precedenti due parametri valgono ''nome_suite-backports'' e ''nome_codename-backports'', viceversa quello di ''deb-multimedia'' usa gli stessi identici valori di quelli principali.
* 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, ad esempio
* Questa direttiva influenza la priorità del repository principale di una release, nonché di quella relativa alla sua sicurezza, per esempio:
** <code>deb http://ftp.it.debian.org/debian/ wheezy main</code>
** <code>deb http://ftp.it.debian.org/debian/ jessie main</code>
** <code>deb http://security.debian.org/ wheezy/updates main</code>
** <code>deb http://security.debian.org/ jessie/updates main</code>
}}
}}


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 (''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''.
* 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 (''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/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 preferences 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:
<pre>
<pre>
Package: *
Package: *
Pin: release a=release_voluta
Pin: release a=release_voluta
Pin-Priority: 990
Pin-Priority: 990
</pre>
* Qualora si sia definita una release obiettivo in <code>apt.conf</code> allora qualsiasi dichiarazione in <code>preferences</code> riguardante tutti i pacchetti di una certa release sarà ignorata, ad esempio definire
<pre>
Package: *
Pin: release a=testing
Pin-Priority: 1000
</pre>
: è del tutto inutile se poi si usa l'opzione '''-t testing'''. Non è invece inutile una dichiarazione del seguente tipo:
<pre>
Package: specifico pacchetto o espressione regolare
Pin: release a=testing
Pin-Priority: 1000
</pre>
</pre>


Riga 155: Riga 148:
{{Warningbox | Si noti che cercare di retrocedere l'intero sistema, impostando un pinning superiore a 1000 per tutti i pacchetti di una precedente [[release]], '''È UNA FOLLIA!'''
{{Warningbox | Si noti che cercare di retrocedere l'intero sistema, impostando un pinning superiore a 1000 per tutti i pacchetti di una precedente [[release]], '''È UNA FOLLIA!'''


Non è minimamente testata né supportata, in quanto è un'operazione opposta all'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.}}
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 =
= Esempi =
Riga 161: Riga 154:


== Release pura ==
== Release pura ==
Non serve il pinning se si usano i repository ufficiali di una sola release di Debian, ed è '''sconsigliato''' impostare una ''Default-Release'' in <code>apt.conf</code>.
Non serve il pinning se si usano i repository ufficiali di una sola release di Debian, ed è '''sconsigliato''' anche impostare una ''Default-Release'' 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 ''Default-Release''.
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''.


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.
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 ''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 ''backports'' (si legga [[backports|qui]] come attivarli).
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 legga [[backports|qui]] come attivarli).
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à.
=== sources.list ===
<pre>
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
</pre>
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 ===
=== apt.conf ===
Non serve modificarlo.
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 ===
=== preferences ===
Riga 177: Riga 196:
<pre>
<pre>
Package: libreoffice*
Package: libreoffice*
Pin: release n=wheezy-backports
Pin: release n=jessie-backports
Pin-Priority: 990
Pin-Priority: 990
</pre>
</pre>
Riga 190: Riga 209:


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.
=== sources.list ===
<pre>
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
</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 ''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 ===
=== Pinning per un singolo pacchetto ===
Riga 213: Riga 262:
Con questo secondo comando è superfluo l'uso del pinning per "nomepacchetto", se non per ricordarsi la configurazione desiderata.
Con questo secondo comando è superfluo l'uso del pinning per "nomepacchetto", se non per ricordarsi la configurazione desiderata.


Si noti anche che non si avranno aggiornamenti 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 oppure impostare il pinning come una delle due configurazioni trattate in seguito.
{{Box | Aptitude | È possibile anche installare il pacchetto tramite [[aptitude]]:
 
=== Pinning per un pacchetto e le sue dipendenze ===
Per permettere l'installazione e l'aggiornamento automatico di un pacchetto da testing con tutte le sue dipendenze, basta creare il file <code>/etc/apt/preferences.d/miopinning</code> con questo contenuto:
<pre>
<pre>
Package: nomepacchetto dipendenza1 dipendenza2 ...
# aptitude install nomepaccheto
Pin: release a=testing
</pre>
Pin-Priority: 990
facendo risolvere a questo comando il conflitto causato dal pinning del pacchetto e le sue dipendenze, fino ad ottenere la soluzione desiderata.


Package: *
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 <code>-t</code>.}}
Pin: release a=testing
Pin-Priority: -1
</pre>


Ora è sufficiente:
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 <code>aptitude</code> per risolvere i conflitti, oppure impostare il pinning con la configurazione trattata in seguito.
<pre>
# apt-get install nomepacchetto
</pre>
per installarlo e inoltre il pacchetto sarà tenuto aggiornato in automatico, a meno che siano aggiunte nuove dipendenze alla nuova versione disponibile. Infatti in [[testing]] le dipendenze possono essere rimosse o aggiunte.


=== Pinning per tutti i pacchetti di testing e backports ===
=== Pinning per tutti i pacchetti di testing e backports ===
Riga 237: Riga 276:
<pre>
<pre>
Package: *
Package: *
Pin: release a=wheezy-backports
Pin: release a=jessie-backports
Pin-Priority: 200
Pin-Priority: 300


Package: *
Package: *
Pin: release a=testing
Pin: release a=testing
Pin-Priority: 100
Pin-Priority: 200
</pre>
</pre>
Dove ''wheezy-backports'' è il nome della [[suite]] (e il [[codename]], che sono uguali per i [[backports]]) dei repository backports di [[wheezy]] (l'attuale [[stable]]). È 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.
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à:
Ora basterà:
Riga 250: Riga 294:
# apt-get -t testing install nomepacchetto
# apt-get -t testing install nomepacchetto
</pre>
</pre>
per installare nuovi pacchetti da testing, che saranno 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''.
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 ==
La release principale sia [[testing]], quella secondaria [[Sid]]/[[unstable]]. Si legga [[Repository ufficiali|questa guida]] per impostare i repository di entrambe nel file <code>/etc/apt/sources.list</code>.
 
=== sources.list ===
<pre>
deb http://ftp.it.debian.org/debian/ testing main
deb-src http://ftp.it.debian.org/debian/ testing main


== Testing con unstable==
# Aggiornamenti di sicurezza
La release principale sia testing, quella secondaria unstable. Si legga [[Repository ufficiali|questa guida]] per impostare i repository di entrambe nel file <code>/etc/apt/sources.list</code>.
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
</pre>
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]].


=== apt.conf ===
=== apt.conf ===
<pre>
<pre>
APT
APT::Default-Release "testing";
{
        Default-Release "testing";
        Cache-Limit 36000000;
        Get
        {
                AutomaticRemove "true";
                Fix-Broken "true";
                Show-Upgraded "true";
        }
}
Aptitude
{
        Autoclean-After-Update "true";
        Auto-Fix-Broken "true";
}
</pre>
</pre>
Questa configurazione assegna al repository principale e a quello di sicurezza di testing un pinning di 990.


=== preferences ===
=== preferences ===
Non è necessario configurare alcun pinning, ma è sufficiente l'uso di <code>Default-Release</code> nel file <code>apt.conf</code>.
Non è necessario configurare alcun pinning, perché è sufficiente l'uso di <code>Default-Release</code> nel file <code>apt.conf</code>.


=== Osservazioni ===
=== Osservazioni ===
Riga 283: Riga 329:
# Una volta che la versione in testing divenisse uguale a quella presente in unstable, successive versioni presenti soltanto in unstable non sarebbero aggiornate automaticamente, ma servirebbe specificare nuovamente l'opzione '''-t'''/'''--target-release'''.
# Una volta che la versione in testing divenisse uguale a quella presente in unstable, successive versioni presenti soltanto in unstable non sarebbero aggiornate automaticamente, ma servirebbe specificare nuovamente l'opzione '''-t'''/'''--target-release'''.


== Testing con deb-multimedia ==
== Testing con unstable ed experimental ==
Sia testing l'unica release d'interesse, nonché quella obiettivo. 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.
La release principale sia [[testing]], quella secondaria [[Sid]]/[[unstable]] e si utilizzino anche i repository [[experimental]].
 
{{Box|Nota|Questo esempio non permette di retrocedere automaticamente pacchetti già installati da deb-multimedia.}}


=== sources.list ===
=== sources.list ===
Abilitiamo anche le sezioni ''contrib'' e ''non-free'':
Il file <code>/etc/apt/sources.list</code> sarà simile al precedente, con aggiunti i soli repository [[experimental]].
<pre>
<pre>
### Debian testing
deb http://ftp.it.debian.org/debian/ testing main
deb http://ftp.it.debian.org/debian/ testing main contrib non-free
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


### Debian testing - sicurezza
# Unstable
deb http://security.debian.org/ testing/updates main contrib non-free
deb http://ftp.it.debian.org/debian/ sid main
deb-src http://ftp.it.debian.org/debian/ sid main


### repository NON ufficiali - multimedia
# Experimental
deb http://www.deb-multimedia.org testing main non-free
deb http://ftp.it.debian.org/debian/ experimental main
deb-src http://ftp.it.debian.org/debian/ experimental main
</pre>
</pre>
Come nell'esempio precedente 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, per cui è sufficiente ripetere la configurazione vista nell'esempio precedente.  È il motivo per cui, se si utilizzassero soltanto ''sid'' ed ''experimental'' non sarebbe necessario alcun pinning, avendo già priorità differente.


=== apt.conf ===
=== apt.conf ===
<pre>
<pre>
APT
APT::Default-Release "testing";
{
        Cache-Limit 36000000;
        Get
        {
                AutomaticRemove "true";
                Fix-Broken "true";
                Show-Upgraded "true";
        }
}
Aptitude
{
        Autoclean-After-Update "true";
        Auto-Fix-Broken "true";
}
</pre>
</pre>
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 ===
<br/>
Non è necessario configurare alcun pinning, perché è sufficiente l'uso di <code>Default-Release</code> nel file <code>apt.conf</code>.
<pre>
Package: *
Pin: Release o=Unofficial Multimedia Packages
Pin-Priority: 101


Package: *
=== Osservazioni ===
Pin: Release a=Testing
Il funzionamento è simile a quello dell'esempio precedente, in quanto per installare da ''sid'' o ''experimental'' è necessario specificarlo con l'opzione '''-t'''/'''--target-release''', ma i pacchetti installati da ''experimental'' non saranno mai aggiornati in automatico.
Pin-Priority: 990


Package: *
Questo comportamento è del tutto voluto, perché sarebbe troppo pericoloso aggiornare senza supervisione ciò che proviene da quel repository, essendo quello meno testato e con maggiori bug. Per effettuare l'aggiornamento è sufficiente ripetere il comando di installazione:
Pin: release o=Debian
<pre>
Pin-Priority: -10
# apt-get -t experimental install nomepacchetto
</pre>
</pre>


=== Osservazioni ===
== Testing con pacchetti non-free e repository deb-multimedia ==
# 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 989, a deb-multimedia, senza che per questo i suoi candidati ottengano la precedenza su quelli del repository principale. Qualora invece si desiderasse dare la precedenza ai pacchetti di deb-multimedia sarebbe sufficiente definire la release obiettivo in <code>apt.conf</code> risultando perfino inutile definire un file <code>preferences</code>, visto che come già detto di norma i candidati di deb-multimedia hanno numero di versione maggiore di quelli del repository principale.
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.
# L'utilizzo dell'opzione '''-t''' in questo caso è inutile, visto che si lavora per ipotesi con una sola release.
# L'installazione di tutti i pacchetti provenienti da release differenti da testing è completamente impedita, anche nel caso si aggiungessero repository relativi ad altre release (a meno ovviamente di non aggiungere opportuni record in <code>preferences</code>).
# La definizione di un file <code>apt.conf</code> in questo esempio non è necessaria ai fini del pinning.


== Mix di varie release ==
{{Box|Nota|Questo esempio non permette di retrocedere automaticamente pacchetti già installati da deb-multimedia.}}
In questo how-to mostrerò come utilizzare pacchetti Debian provenienti da Testing, Unstable, Experimental e deb-multimedia (audio/video) ma le istruzioni sono facilmente riportabili anche ad altre situazioni (unstable + experimental, stable + testing, stable + unstable, stable + testing + unstable, ecc.).


=== Impostare i repository ===
=== sources.list ===
Assicuriamoci di essere l'utente root e procediamo.
Abilitiamo anche le sezioni ''contrib'' e ''non-free'':
 
Per prima cosa editiamo il file <code>/etc/apt/sources.list</code> ed inseriamo gli archivi dei pacchetti Debian che utilizzeremo, per esempio (con ''contrib'' e ''non-free'' abilitati):
<pre>
<pre>
### Debian Ufficiale -- Testing
### Debian testing
deb http://ftp.it.debian.org/debian/ testing main contrib non-free
deb http://ftp.it.debian.org/debian/ testing main contrib non-free


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


### Debian Ufficiale -- Sid
### repository NON ufficiali - multimedia
deb http://ftp.it.debian.org/debian/ unstable main contrib non-free
 
###  Debian Ufficiale -- Experimental
deb http://ftp.it.debian.org/debian/ experimental main contrib non-free
 
### deb-multimedia -- Audio/Video -- Marillat
deb http://www.deb-multimedia.org testing main non-free
deb http://www.deb-multimedia.org testing main non-free
</pre>
</pre>


=== Configurare apt ===
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.
A questo punto dobbiamo preparare due file normalmente non presenti sulla nostra debianbox: si tratta dei file <code>/etc/apt/preferences</code> e <code>/etc/apt/apt.conf</code>.
Questi due file istruiranno APT su come gestire le dipendenze dei pacchetti, informandolo su come comportarsi in caso di conflitti e altri problemi.


==== Il file <code>apt.conf</code> ====
=== apt.conf ===
Ora creiamo il file <code>/etc/apt/apt.conf</code>
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'''.


<pre># touch /etc/apt/apt.conf</pre>
=== preferences ===
 
ed editiamolo inserendo quanto segue:
<pre>
APT::Cache-Limit 15000000;
APT::Clean-Installed;
APT::Get::Fix-Broken;
APT::Get::Show-Upgraded "true";
</pre>
 
'''Nota''': la sintassi usata in quest'esempio, pur essendo differente da quella dei precedenti, è del tutto equivalente. Anche in questo caso è bene sottolineare che la definizione di un file <code>apt.conf</code> non è necessaria ai fini del pinning.
 
==== Il file <code>preferences</code> ====
Creiamo il file <code>/etc/apt/preferences</code>:
<pre># touch /etc/apt/preferences</pre>
 
ed editiamolo col nostro editor di fiducia e inseriamo queste direttive:
<pre>
<pre>
Package: *
Package: *
Pin: release a=unstable
Pin: Release o=Unofficial Multimedia Packages
Pin-Priority: 400
Pin-Priority: 100
</pre>
</pre>


Si noti che ''experimental'' ha un ''Pin-Priority'' implicito pari a 1, e che quelli non specificati hanno un valore di 500, pertanto non è necessario impostare regole per ''deb-multimedia'' e ''testing'', che sarebbero equivalenti, ed ''experimental''.
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.


Facciamo l'update del database dei pacchetti:
=== Osservazioni ===
<pre># apt-get update</pre>
* Poiché entrambe le fonti, ''principale'' e ''deb-multimedia'', appartengono alla release testing in teoria questo caso non sarebbe gestibile tramite pinning, tuttavia sotto l'ipotesi di voler installare da deb-multimedia solo i pacchetti non presenti nella fonte principale il problema è risolvibile. Evitando di definire in <code>apt.conf</code> una release obiettivo e definendo in <code>preferences</code> prima il record relativo a deb-multimedia si ottiene di riuscire ad assegnare la priorità desiderata, nonostante il fatto che il secondo record si applichi in teoria anche a deb-multimedia. Si noti che stanti così le cose dovrebbe essere in realtà possibile attribuire pin superiori, fino a 499, a deb-multimedia, senza che per questo i suoi candidati ottengano la precedenza su quelli del repository principale.
 
* L'utilizzo dell'opzione '''-t''' in questo caso è inutile, visto che si lavora per ipotesi con una sola release.
D'ora in avanti avremo due possibilità per installare un nuovo pacchetto: il metodo che usiamo di solito e cioè:
<pre># apt-get install nome_pacchetto</pre>
che utilizzerà pacchetti proveniente dalla versione impostata come '''Default-Release''' in '''apt.conf''', oppure il comando
<pre># apt-get install -t versione_di_debian nome_pacchetto</pre>
che provvederà a installare il pacchetto da noi richiesto per la versione specificata (versione_debian), risolvendo automaticamente le dipendenze.


= Comandi utili =
= Comandi utili =
Riga 426: Riga 427:
|Verificata_da =
|Verificata_da =
: [[Utente:Wtf|Wtf]]
: [[Utente:Wtf|Wtf]]
: [[Utente:HAL 9000|HAL 9000]] 14:08, 9 apr 2015 (CEST)
: [[Utente:HAL 9000|HAL 9000]] 16:01, 9 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]]
3 581

contributi

Menu di navigazione