Repository & pinning: differenze tra le versioni

Vai alla navigazione Vai alla ricerca

Repository & pinning (visualizza wikitesto)

Versione delle 20:40, 22 apr 2016

4 468 byte aggiunti ,  22 apr 2016
m
→‎Testing con unstable ed experimental: avviso link
(14 versioni intermedie di uno stesso utente non sono mostrate)
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 '''<code>-t release_voluta</code>''' 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>''' (anche nella forma <code>--target-release release_voluta</code>) in [[apt-get]], [[apt]] e [[aptitude]].
 
Tale dichiarazione:
* attribuisce priorità 990 a tutti i pacchetti appartenenti alla [[release]] specificata;
* ignora tutte le impostazioni di pinning in <code>/etc/apt/preferences</code> riguardanti la stessa release e relative a tutti i pacchetti (anziché a un singolo pacchetto o a un gruppo di pacchetti).
 
Pertanto si raccomanda di '''non''' impostare una <code>Default-Release</code> se si vuole utilizzare anche il file <code>/etc/apt/preferences</code>, per non creare conflitti tra le due configurazioni.


{{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 ''jessie''.
* Tale priorità si applica alla release e non alla fonte, quindi ad ottenere la suddetta priorità non saranno solo i pacchetti appartenenti al repository principale (o ai due repository principali), ma anche quelli provenienti da altre fonti se il gestore di tale repository usa lo stesso valore per i parametri [[suite]] e [[codename]] di quelli principali, ad esempio ''stable'' e ''{{Codename|stable}}''.
* 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:
** <code>deb http://ftp.it.debian.org/debian/ jessie main</code>
** <code>deb <nowiki>http://ftp.it.debian.org/debian/</nowiki> {{Codename|stable}} main</code>
** <code>deb http://security.debian.org/ jessie/updates main</code>
** <code>deb <nowiki>http://security.debian.org/</nowiki> {{Codename|stable}}/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 (<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.
* Le dichiarazioni di parametri da riga di comando hanno sempre la precedenza su quelli definiti in un file di configurazione, che di conseguenza verranno ignorati, quindi usare un comando del tipo <code>apt-get install pacchetto -t release_taldeitali</code> disabilita durante l'esecuzione qualunque release obiettivo (<code>Default-Release</code>) dichiarata nel file <code>apt.conf</code>. Perciò avere un pinning a 990 in <code>preferences</code> non è necessariamente equivalente a impostare una <code>Default-Release</code>, anche in assenza di conflitti tra i due file di configurazione.
* Definire una release obiettivo in <code>apt.conf</code> è equivalente a dichiarare in <code>preferences</code> (si veda la prossima sezione) quanto segue:
<pre>
Package: *
Pin: release a=release_voluta
Pin-Priority: 990
</pre>


{{Box|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)}}
{{Box|File multipli|L'utente può, invece di creare un unico file di nome <code>apt.conf</code>, creare più file di nome arbitrario in <code>/etc/apt/apt.conf.d/</code> (si veda il manuale)}}


= /etc/apt/preferences =
= /etc/apt/preferences =
Questo è il file dove è possibile definire tutte le priorità che si vogliono, fermo restando quanto detto nella sezione dedicata ad <code>apt.conf</code>. La sintassi generale è la seguente:
Questo è il file dove è possibile definire tutte le priorità che si vogliono, fermo restando quanto detto nella sezione dedicata ad <code>apt.conf</code> di utilizzare soltanto uno dei file per il pinning. La sintassi generale è la seguente:
<pre>
<pre>
Package: nome pacchetto o espressione regolare
Package: nome pacchetto o espressione regolare
Riga 109: Riga 108:
Pin-Priority: numero
Pin-Priority: numero
</pre>
</pre>
Un paio di esempi del tutto arbitrari:
 
<pre>
Un po' di esempi del tutto arbitrari:
Package: vlc
 
Pin: release a=testing
Package: vlc
Pin-Priority: 991
Pin: release a=testing
   
Pin-Priority: 991
Package: virtualbox4*
 
Pin: Release o=Oracle Corporation
Package: vlc
Pin-Priority: 780
Pin: release n={{Codename|testing}}
</pre>
  Pin-Priority: 991
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.
 
Package: virtualbox4*
Pin: Release o=Oracle Corporation
Pin-Priority: 780
 
Il primo e il secondo esempio sono equivalenti, il primo fa riferimento alla [[suite]] (detta anche '''''a'''rchive'') mentre il secondo al [[codename]] ('''''n'''ome in codice''). In entrambi si è definito il pinning per il pacchetto di nome "vlc", richiedendo che le versioni appartenenti alla release testing, attualmente [[{{Codename|Testing}}]], abbiano priorità 991. Attenzione però che quando {{Codename|Testing}} diverrà la nuova [[stable]], il primo si applicherà alla nuova testing mentre il secondo continuerà a far riferimento a {{Codename|Testing}}. Solitamente è consigliabile il secondo (con ''codename''), se si utilizza una stable e si vogliono prelevare pacchetti da testing, mentre il primo (con ''suite'') se si utilizza una testing e si vuole restare sempre con quella. La scelta dovrebbe inoltre riflettere quella adottata per tutti i repository in <code>/etc/apt/sources.list</code>, tenendo presente anche che i [[backports]] contengono sempre il ''codename''.
 
Nel terzo esempio invece, sfruttando un semplicissimo pattern, 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".
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".
Riga 150: Riga 156:
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.}}
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 senza bisogno di pinning =
{{Box|Nota|Per il significato dei vari parametri dichiarati in <code>apt.conf</code>, nonché per la relativa sintassi, si vedano le guide dedicate ad [[apt-get]], ecc. Si ricordi inoltre che non sempre la definizione di tale file è necessaria ai fini del pinning.}}


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


Infatti ciò avrebbe effetto sul repository principale e su quello della sicurezza, ma non sugli eventuali ''updates'' o ''proposed-updates'', che non sarebbero più aggiornati automaticamente, salvo che per i pacchetti già installati da quei repository. Per riabilitare gli aggiornamenti automatici sarebbe necessario impostare un pinning a 990, pari a quello della <code>Default-Release</code>.
Infatti ciò avrebbe effetto sul repository principale e su quello della sicurezza, 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 backports verranno aggiornati automaticamente.
== Stable con backports ==
Non è necessario alcun pinning nemmeno aggiungendo i [[backports]] ai repository della [[stable]] (attualmente [[{{Codename|Stable}}]]), in quanto di default sono disattivati, a eccezione dei pacchetti presenti soltanto lì, e consentono solo l'aggiornamento automatico dei pacchetti installati manualmente dai backports.
 
Per installare un pacchetto dai backports la prima volta, basta utilizzare [[apt]] (o equivalentemente [[apt-get]]):
# apt -t {{Codename|stable}}-backports install nomepacchetto


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.
Per esempio per installare <code>libreoffice</code>:
# apt -t {{Codename|stable}}-backports install libreoffice


== Stable con backports obbligati ==
Dopo di che sarà aggiornato automaticamente assieme agli altri pacchetti di {{Codename|Stable}} con:
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]].
<pre>
# apt update
# apt upgrade
</pre>
Si noti invece che potrebbe essere necessario un <code>dist-upgrade</code> se si utilizza [[apt-get]].


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à.
=== Backports automatici ===
{{Warningbox | Questo esempio '''non''' è consigliato, ma intende soltanto mostrare alcune delle problematiche nella configurazione del pinning.


=== sources.list ===
Si ricorda infatti 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à, come visto nella sezione precedente.}}
<pre>
deb http://ftp.it.debian.org/debian/ jessie main
deb-src http://ftp.it.debian.org/debian/ jessie main


# Aggiornamenti di sicurezza
Si supponga di voler usare tutti i pacchetti della [[stable]], con l'eccezione di quelli relativi a <code>libreoffice</code> che si vuole siano prelevati esclusivamente dai [[backports]]. È bene chiarire subito che '''non esiste alcun modo di garantire ciò''' tramite il pinning, poiché le [[dipendenze]] di un pacchetto non sono influenzate dalla sua ''Pin-Priority''. Quello che si può fare è trovare una soluzione di compromesso, che è quasi sempre più svantaggiosa di quella proposta nella sezione precedente, ossia non utilizzando alcun pinning.
deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main


# Aggiornamenti raccomandati
Infatti è possibile soltanto impedire l'installazione dei pacchetti dalla stable quando presenti anche nei backports. Questo perché, per soddisfare tutte le possibili dipendenze dei pacchetti installati, l'unico modo sarebbe assegnare una ''Pin-Priority'' di almeno 500 a tutti i pacchetti provenienti dai backports, che di default ne hanno una di 100.
deb http://ftp.it.debian.org/debian/ jessie-updates main
deb-src http://ftp.it.debian.org/debian/ jessie-updates main


# Backports
Le principali alternative, presentate a solo scopo didattico:
deb http://ftp.it.debian.org/debian/ jessie-backports main
* nessuna <code>Default-Release</code> in <code>apt.conf</code> e file <code>/etc/apt/preferences</code> come segue
deb-src http://ftp.it.debian.org/debian/ jessie-backports main
Package: libreoffice
</pre>
Pin: release n={{Codename|stable}}-backports
Pin-Priority: 500
* nessuna <code>Default-Release</code> in <code>apt.conf</code> e file <code>/etc/apt/preferences</code> come segue
Package: libreoffice*
Pin: release n={{Codename|stable}}-backports
Pin-Priority: 500
* nessuna impostazione in <code>/etc/apt/preferences</code> e file <code>/etc/apt/apt.conf</code> come segue
APT::Default-Release "{{Codename|stable}}-backports";


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.
La prima possibilità restituisce errore quando si cerca di installare il pacchetto, costringendo a ricorrere all'opzione <code>-t</code> oppure lasciando ad [[aptitude]] il compito di risolvere i conflitti. In modo analogo può restituire errore durante un aggiornamento, se richiede anche l'aggiornamento delle sue [[dipendenze]], costringendo a ripetere il comando di installazione con <code>-t</code>.


Di default si ricordi che tutti i repository hanno una priorità di 500, a eccezione di '''jessie-backports''' che ne hanno una di 100.
La seconda possibilità riesce più spesso, in quanto quasi tutte le dipendenze cominciano con la stringa ''libreoffice'' e sono quindi catturate dal pattern ''libreoffice'''*''''', tuttavia nemmeno ciò garantisce il funzionamento automatico in ogni circostanza, per via di possibili altre dipendenze con altri nomi. E anche se aggiungessimo pure tali pacchetti, si aumenterebbe soltanto la frequenza di successo, senza però mai avere una garanzia nella totalità dei casi, visto che nuove dipendenze potrebbero essere aggiunte in successivi aggiornamenti.


=== apt.conf ===
La terza alternativa è l'unica che funziona sempre in automatico, ma si applica indiscriminatamente a tutti i pacchetti contenuti nei ''backports'', che è proprio quello che si voleva evitare per una [[stable]].
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 ===
{{Box | Backports obbligatori | Specificando una priorità di 990 anziché 500 nel file <code>/etc/apt/preferences</code>, come visto in questa sezione, l'installazione di <code>libreoffice</code> dai repository non backports fallirebbe anche utilizzando l'opzione <code>-t {{Codename|stable}}</code>, rendendo l'installazione da ''{{Codename|stable}}-backports'' l'unica possibile (anche se non garantita senza l'uso dell'opzione <code>-t {{Codename|stable}}-backports</code>).
<br/>
<pre>
Package: *
Pin: release a=stable
Pin-Priority: 991


Package: libreoffice*
Si noti invece che l'uso dei backports non è obbligatorio specificando la <code>Default-Release</code> a ''{{Codename|stable}}-backports'', per le ragioni già esposte nella sezione su <code>apt.conf</code> di questa guida, anche se lo sarebbero gli aggiornamenti (in assenza di conflitti con le dipendenze).}}
Pin: release n=jessie-backports
Pin-Priority: 992


Package: *
== Unstable/Sid ed experimental ==
Pin: release n=jessie-backports
Se si utilizzino soltanto i repository [[sid]] ed [[experimental]] non è 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.
Pin-Priority: 990
</pre>


=== Osservazioni ===
Per installare o aggiornare un pacchetto da experimental, basta eseguire:
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.
<pre># apt-get -t experimental install nomepacchetto</pre>


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:
= Esempi con pinning =
<pre># apt-get -t jessie-backports install libreoffice</pre>


== Stable con testing ==
== Stable con testing ==
Riga 222: Riga 226:


=== sources.list ===
=== sources.list ===
<pre>
deb <nowiki>http://ftp.it.debian.org/debian/</nowiki> {{Codename|stable}} main
deb http://ftp.it.debian.org/debian/ jessie main
deb-src <nowiki>http://ftp.it.debian.org/debian/</nowiki> {{Codename|stable}} main
deb-src http://ftp.it.debian.org/debian/ jessie main
# Aggiornamenti di sicurezza
deb <nowiki>http://security.debian.org/</nowiki> {{Codename|stable}}/updates main
deb-src <nowiki>http://security.debian.org/</nowiki> {{Codename|stable}}/updates main
# Aggiornamenti raccomandati
deb <nowiki>http://ftp.it.debian.org/debian/</nowiki> {{Codename|stable}}-updates main
deb-src <nowiki>http://ftp.it.debian.org/debian/</nowiki> {{Codename|stable}}-updates main
# Backports
deb <nowiki>http://ftp.it.debian.org/debian/</nowiki> {{Codename|stable}}-backports main
deb-src <nowiki>http://ftp.it.debian.org/debian/</nowiki> {{Codename|stable}}-backports main
# Testing
deb <nowiki>http://ftp.it.debian.org/debian/</nowiki> {{Codename|testing}} main
deb-src <nowiki>http://ftp.it.debian.org/debian/</nowiki> {{Codename|testing}} main
# Aggiornamenti di sicurezza di testing
deb <nowiki>http://security.debian.org/</nowiki> {{Codename|testing}}/updates main
deb-src <nowiki>http://security.debian.org/</nowiki> {{Codename|testing}}/updates main


# Aggiornamenti di sicurezza
Quello mostrato è solo un esempio con i due repository principali di [[{{Codename|Stable}}]], 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 [[{{Codename|Testing}}]] ([[testing]]).
deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main


# Aggiornamenti raccomandati
Questo file è valido per tutti gli esempi di questa sezione, mentre gli altri dipendono dalla configurazione del pinning desiderata. Si noti in particolare la scelta del [[codename]] (''{{Codename|testing}}'') al posto della [[suite]] (''testing''), che è la configurazione consigliata in presenza di una [[stable]] e verrà quindi mantenuta anche per il pinning.
deb http://ftp.it.debian.org/debian/ jessie-updates main
deb-src http://ftp.it.debian.org/debian/ jessie-updates main


# Backports
=== apt.conf ===
deb http://ftp.it.debian.org/debian/ jessie-backports main
Non si utilizza in questo caso, per non creare conflitti con il file <code>/etc/apt/preferences</code>. Assicurarsi perciò che <code>/etc/apt/apt.conf</code> non contenga una riga su <code>Default-Release</code>, che se presente va cancellata.
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 ===
Creare il file <code>/etc/apt/preferences</code> con questo contenuto:
Creare il file <code>/etc/apt/preferences</code> con questo contenuto:
<pre>
Package: nomepacchetto
Package: nomepacchetto
Pin: release n={{Codename|testing}}
Pin: release a=testing
Pin-Priority: 990
Pin-Priority: 990
Package: *
Pin: release n={{Codename|testing}}
Pin-Priority: -1


Package: *
Questa configurazione si consiglia soltanto per pacchetti che non richiedono l'installazione di altri da testing.
Pin: release a=testing
Pin-Priority: -1
</pre>


Adesso è possibile installare il pacchetto "nomepacchetto" da testing con:
Si può controllarne il funzionamento con:
<pre>
<pre>
# apt-get install nomepacchetto
$ apt-get --simulate install nomepacchetto
</pre>
oppure in caso di dipendenze con:
<pre>
# apt-get -t testing install nomepacchetto
</pre>
</pre>
Con questo secondo comando è superfluo l'uso del pinning per "nomepacchetto", se non per ricordarsi la configurazione desiderata.
(e si può usare la forma abbreviata <code>-s</code> al posto di <code>--simulate</code>)


{{Box | Aptitude | È possibile anche installare il pacchetto tramite [[aptitude]]:
In assenza di problemi, sarà possibile installare il pacchetto "nomepacchetto" da testing semplicemente con:
<pre>
<pre>
# aptitude install nomepaccheto
# apt-get install nomepacchetto
</pre>
</pre>
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 <code>-t</code>.}}
In presenza di dipendenze, o si aggiungono al file <code>preferences</code> se non sono molte, oppure si consiglia la configurazione presentata nella sezione successiva.


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.
{{Warningbox | Infatti mentre sarebbe possibile forzarne l'installazione con:
# apt-get -t {{Codename|testing}} install nomepacchetto
c'è da considerare che l'uso dell'opzione <code>-t</code> renderebbe il pinning per "nomepacchetto" superfluo; e inoltre la configurazione attuale impedirebbe gli aggiornamenti automatici delle dipendenze appena installate, costringendo a ripetere il comando precedente in caso di conflitti oppure ad avvelersi di [[aptitude]] per risolverli (prestando '''molta attenzione''' alle soluzioni proposte).}}


=== 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</code> come segue:
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>
Package: *
Package: *
Pin: release a={{Codename|stable}}-backports
Pin: release a=jessie-backports
Pin-Priority: 300
Pin-Priority: 300
 
Package: *
Package: *
Pin: release n={{Codename|testing}}
Pin: release a=testing
Pin-Priority: 200
Pin-Priority: 200
Dove ''{{Codename|stable}}-backports'' è il nome della [[suite]] (e il [[codename]], che sono uguali per i [[backports]]) dei repository backports di [[{{Codename|Stable}}]]. È consigliabile specificare la nuova priorità a prescindere dalla loro presenza, altrimenti se attivati saranno sempre nascosti da [[{{Codename|Testing}}]], avendo di default una priorità di 100 e contenendo versioni non più aggiornate.
</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 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'';
* ''{{Codename|stable}}-backports'' deve avere una priorità inferiore a quella di default (500), utilizzata per ''{{Codename|stable}}'' e ''{{Codename|stable}}-updates'';
* testing deve avere una priorità inferiore a quella scelta per ''jessie-backports'';
* ''{{Codename|testing}}'' deve avere una priorità inferiore a quella scelta per ''{{Codename|stable}}-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.
* ''{{Codename|testing}}'' e ''{{Codename|stable}}-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à:
<pre>
# apt-get -t {{Codename|testing}} install nomepacchetto
# apt-get -t testing install nomepacchetto
per installare nuovi pacchetti da {{Codename|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> oppure il meccanismo di risoluzione dei conflitti di [[aptitude]], se nuove dipendenze fossero aggiunte nello stesso ramo.
</pre>
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 ==
<!--
  NOTA: *NON* cambiare il nome della sezione "Testing con unstable ed experimental", perché è utilizzata da altre guide.
-->
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]].  


Riga 339: Riga 340:
</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.
Come nel <code>sources.list</code> la release è indicata per ''suite''.
 
Questa configurazione assegna al repository principale e a quello di sicurezza di testing una ''Pin-Priority'' di 990. Di conseguenza sid resta a 500 ed experimental a 1.


=== preferences ===
=== preferences ===
Riga 359: Riga 362:
Abilitiamo anche le sezioni ''contrib'' e ''non-free'':
Abilitiamo anche le sezioni ''contrib'' e ''non-free'':
<pre>
<pre>
### Debian 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 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


### repository NON ufficiali - multimedia
# repository NON ufficiali - multimedia
deb http://www.deb-multimedia.org testing main non-free
deb http://www.deb-multimedia.org testing main non-free
</pre>
</pre>


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.
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 ===
=== apt.conf ===
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.
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 381: Riga 384:
</pre>
</pre>


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.
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 ===
=== 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 <code>-t</code>/<code>--target-release</code> in questo caso è inutile, visto che si lavora per ipotesi con una sola release.
* 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.


Riga 393: Riga 396:
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>
Si consiglia anche l'installazione di [[apt-show-versions]], per poter controllare velocemente da quali repository provengono i pacchetti installati sul sistema.


E per controllare se è stata impostata una <code>Default-Release</code> basta:
E per controllare se è stata impostata una <code>Default-Release</code> basta:
<pre>$ apt-config dump | grep -i "^APT::Default-Release"</pre>
<pre>$ apt-config dump | grep -i default-release</pre>
che visualizza la riga relativa solo se presente.
che visualizza la riga relativa solo se presente.


Riga 410: Riga 415:
|Verificata_da =
|Verificata_da =
: [[Utente:Wtf|Wtf]]
: [[Utente:Wtf|Wtf]]
: [[Utente:HAL 9000|HAL 9000]] 13:09, 10 mag 2015 (CEST)
: [[Utente:HAL 9000|HAL 9000]] 13:01, 11 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]]
HAL 9000
3 581

contributi

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

Menu di navigazione