3 581
contributi
Repository & pinning: differenze tra le versioni
m
→preferences
(task Revisione Wiki #61) |
m (→preferences) |
||
| (7 versioni intermedie di uno stesso utente non sono mostrate) | |||
| Riga 14: | Riga 14: | ||
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. | 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. | ||
{{ | {{Cautionbox|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]] o [[apt-get]].}} | ||
{{Box|Importante|Il pinning è uno strumento per regolare la priorità in base al numero di versione dei pacchetti, e non alla provenienza. Non è possibile discriminare tra pacchetti aventi la stessa versione e provenienti da più repository, ovvero ad essere installato sarà quello proveniente dal repository elencato per primo nel file <code>/etc/apt/sources.list</code>.}} | {{Box|Importante|Il pinning è uno strumento per regolare la priorità in base al numero di versione dei pacchetti, e non alla provenienza. Non è possibile discriminare tra pacchetti aventi la stessa versione e provenienti da più repository, ovvero ad essere installato sarà quello proveniente dal repository elencato per primo nel file <code>/etc/apt/sources.list</code>.}} | ||
| Riga 34: | Riga 33: | ||
* non è stato dichiarato il parametro ''Default Release'' in un eventuale file <code>apt.conf</code>, ovvero non è stata definita una release obiettivo. | * non è stato dichiarato il parametro ''Default Release'' in un eventuale file <code>apt.conf</code>, ovvero non è stata definita una release obiettivo. | ||
Nel momento in cui l'utente esegue il comando <code>apt | Nel momento in cui l'utente esegue il comando <code>apt install vattelapesca</code> sarà assegnata una priorità di 500 ai "vattelapesca" di repoA, repoB e repoC.<br/> | ||
Il pacchetto da repoC viene immediatamente scartato perché implicherebbe la retrocessione ([[downgrade]]) dello stesso. A questo punto APT sceglierà tra repoA e repoB in base alla versione, e quindi a essere installato sarà quello da repoB e non da repoA come desiderato. | Il pacchetto da repoC viene immediatamente scartato perché implicherebbe la retrocessione ([[downgrade]]) dello stesso. A questo punto APT sceglierà tra repoA e repoB in base alla versione, e quindi a essere installato sarà quello da repoB e non da repoA come desiderato. | ||
Il problema evidentemente non può che esplodere quando si tenta di aggiornare tutti i pacchetti di sistema. | Il problema evidentemente non può che esplodere quando si tenta di aggiornare tutti i pacchetti di sistema. | ||
| Riga 75: | Riga 74: | ||
= /etc/apt/apt.conf = | = /etc/apt/apt.conf = | ||
Questo file insieme ad altri permette di definire le opzioni di APT e relativi strumenti senza bisogno di digitarli sempre da riga di comando. Si vedano le guide dedicate ad [[apt-get]] e [[ | Questo file insieme ad altri permette di definire le opzioni di APT e relativi strumenti senza bisogno di digitarli sempre da riga di comando. Si vedano le guide dedicate ad [[apt-get]] e [[aptitude]] per dei brevi esempi contenenti alcuni dei parametri più comuni.<br/> | ||
Per quanto riguarda il pinning l'unico parametro strettamente di rilievo è: | Per quanto riguarda il pinning l'unico parametro strettamente di rilievo è: | ||
<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>''' (anche nella forma <code>--target-release release_voluta</code>) in [[apt | 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]], [[apt-get]] e [[aptitude]]. | ||
Tale dichiarazione: | Tale dichiarazione: | ||
| Riga 86: | Riga 85: | ||
* 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). | * 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. | 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. In questa guida ora '''si sconsiglia sempre''' l'uso di una <code>Default-Release</code>, per via dei cambiamenti introdotti a ''codename'' e ''suite'' di un repository di sicurezza a partire da Debian 11 ([[Bullseye]]). | ||
{{ | {{Cautionbox| | ||
* 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}}''. | * 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}}''. | ||
* Questa direttiva | * Questa direttiva fino a Debian 10 ([[Buster]]) ha influenzato la priorità del repository principale di una release, nonché di quella relativa alla sua sicurezza, motivo per cui era abbastanza utile in alcune situazioni, per esempio nel caso di '''buster''' avrebbe influenzato entrambi i repository: <br/> <code>deb {{APT-mirror}} buster main</code> <br/> <code>deb {{APT-mirror|security}} buster/updates main</code> | ||
* A partire da Debian 11 ([[Bullseye]]) però il repository di sicurezza ha ''codename'' e ''suite'' propri: ''codename'''''-security''' e ''suite'''''-security''' rispettivamente; ossia nel caso di '''bullseye''': <br/> <code>deb {{APT-mirror|security}} bullseye'''-security''' main</code> <br/> E pertanto l'uso di una <code>Default-Release</code> '''non''' influenzerà più il repository di sicurezza, di fatto disabilitandolo!}} | |||
* | |||
}} | |||
Si noti inoltre che: | Si noti inoltre che: | ||
* Comandi del tipo <code>apt | * Comandi del tipo <code>apt 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- | * 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 -t release_taldeitali install pacchetto</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. | ||
{{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)}} | {{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)}} | ||
| Riga 161: | Riga 157: | ||
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>. | 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 (solo fino a Debian 10 [[Buster]]), 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>. | ||
E a partire da Debian 11 ([[Bullseye]]) perfino gli aggiornamenti di sicurezza sarebbero bloccati! | |||
== Stable con backports == | == Stable con backports == | ||
| Riga 180: | Riga 177: | ||
=== Backports automatici === | === Backports automatici === | ||
{{ | {{Cautionbox | Questo esempio '''non''' è consigliato, ma intende soltanto mostrare alcune delle problematiche nella configurazione del pinning. | ||
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.}} | 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.}} | ||
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. | 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. | ||
| Riga 214: | Riga 210: | ||
Per installare o aggiornare un pacchetto da experimental, basta eseguire: | Per installare o aggiornare un pacchetto da experimental, basta eseguire: | ||
<pre># apt | <pre># apt -t experimental install nomepacchetto</pre> | ||
= Esempi con pinning = | = Esempi con pinning = | ||
== Stable con testing == | == Stable con testing == | ||
{{ | {{Cautionbox | Senza pinning ci si troverebbe con una testing effettuando gli aggiornamenti del sistema. | ||
Ma anche con il pinning c'è il pericolo che a ogni aggiornamento aumenti la possibilità che nuove dipendenze da testing siano necessarie, rendendo la provenienza dei pacchetti della propria distribuzione sempre più mista, senza i benefici di nessuna delle due e quindi in una situazione meno desiderabile di un passaggio diretto a testing.}} | 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. | ||
=== sources.list === | === sources.list === | ||
deb | {{Cautionbox | Si ricorda che a partire da Debian 11 ([[Bullseye]]) i repository di sicurezza andranno scritti con la dicitura ''release'''''-security''' (anziché ''release'''''/updates'''); per esempio nel caso di bullseye: | ||
deb-src | deb {{APT-mirror|security}} bullseye'''-security''' main }} | ||
# Stable | |||
deb {{APT-mirror}} {{Codename|stable}} main | |||
deb-src {{APT-mirror}} {{Codename|stable}} main | |||
# Aggiornamenti di sicurezza | # Aggiornamenti di sicurezza | ||
deb | deb {{APT-mirror|security}} {{Codename|stable}}{{#ifeq: {{Codename|stable}} | buster | /updates | -security }} main | ||
deb-src | deb-src {{APT-mirror|security}} {{Codename|stable}}{{#ifeq: {{Codename|stable}} | buster | /updates | -security }} main | ||
# Aggiornamenti raccomandati | # Aggiornamenti raccomandati | ||
deb | deb {{APT-mirror}} {{Codename|stable}}-updates main | ||
deb-src | deb-src {{APT-mirror}} {{Codename|stable}}-updates main | ||
# Backports | # Backports | ||
deb | deb {{APT-mirror}} {{Codename|stable}}-backports main | ||
deb-src | deb-src {{APT-mirror}} {{Codename|stable}}-backports main | ||
# Testing | # Testing | ||
deb | deb {{APT-mirror}} {{Codename|testing}} main | ||
deb-src | deb-src {{APT-mirror}} {{Codename|testing}} main | ||
# Aggiornamenti di sicurezza di testing | # Aggiornamenti di sicurezza di testing | ||
deb | deb {{APT-mirror|security}} {{Codename|testing}}-security main | ||
deb-src | deb-src {{APT-mirror|security}} {{Codename|testing}}-security main | ||
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]]). | 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]]). | ||
| Riga 276: | Riga 274: | ||
In assenza di problemi, sarà possibile installare il pacchetto "nomepacchetto" da testing semplicemente con: | In assenza di problemi, sarà possibile installare il pacchetto "nomepacchetto" da testing semplicemente con: | ||
<pre> | <pre> | ||
# apt | # apt install nomepacchetto | ||
</pre> | </pre> | ||
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. | 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. | ||
{{ | {{Cautionbox | Infatti mentre sarebbe possibile forzarne l'installazione con: | ||
# apt | # apt -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).}} | 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: | ||
| Riga 302: | Riga 299: | ||
Ora basterà: | Ora basterà: | ||
# apt | # apt -t {{Codename|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. | 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. | ||
== 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]]. | ||
=== sources.list === | === sources.list === | ||
deb {{APT-mirror}} testing main | |||
deb | deb-src {{APT-mirror}} testing main | ||
deb-src | |||
# Aggiornamenti di sicurezza | |||
# Aggiornamenti di sicurezza | deb {{APT-mirror|security}} testing-security main | ||
deb | deb-src {{APT-mirror|security}} testing-security main | ||
deb-src | |||
# Unstable | |||
# Unstable | deb {{APT-mirror}} sid main | ||
deb | deb-src {{APT-mirror}} sid main | ||
deb-src | |||
# Experimental | |||
# Experimental | deb {{APT-mirror}} experimental main | ||
deb | deb-src {{APT-mirror}} experimental main | ||
deb-src | |||
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]]. | 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]]. | ||
| Riga 333: | Riga 331: | ||
=== apt.conf === | === apt.conf === | ||
< | Assicurarsi che '''non''' sia impostata una <code>Default-Release</code> per non disabilitare gli aggiornamenti di sicurezza ('''testing-security'''). | ||
[[Testing]] tipicamente non riceve comunque aggiornamenti di sicurezza da questo repository, se non quando non è possibile il porting da [[Sid]], ma è sempre meglio tenerlo abilitato. | |||
=== preferences === | |||
In questo modo entrambi i repository '''testing''' e '''testing-security''' avranno priorità maggiore di '''sid''': | |||
Package: * | |||
Pin: release a=testing-security | |||
Pin-Priority: 990 | |||
Package: * | |||
Pin: release a=testing | |||
Pin-Priority: 990 | |||
Si noti che questa configurazione era equivalente a impostare la <code>Default-Release</code> a '''testing''' nel file <code>/etc/apt/apt.conf</code>, prima dei cambiamenti a [[codename]] e [[suite]] dei repository di sicurezza introdotti con Debian 11 ([[Bullseye]]). | |||
Alternativamente sarebbe possibile anche impostare una priorità inferiore per '''sid''', purché almeno uguale a '''100'''. Per esempio: | |||
Package: * | |||
Pin: release n=sid | |||
Pin-Priority: 100 | |||
Con entrambe le configurazioni il repository di '''sid''' sarebbe equivalente a quello dei [[Il repository Backports|backports]]; ossia verrebbe consentito l'aggiornamento automatico dei pacchetti installati, ma non l'installazione automatica di nuovi pacchetti (se presenti anche in '''testing'''). | |||
=== 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. | # 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 | # Digitando <code>apt -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 upgrade</code> o <code>apt full-upgrade</code> continueranno a installare la versione più recente, anche prelevandola automaticamente da sid, almeno finché la versione in testing non diverrà equivalente. | ||
# Una volta che la versione in testing divenisse uguale a quella presente in sid, successive versioni presenti soltanto in sid non sarebbero aggiornate automaticamente, ma servirebbe specificare nuovamente l'opzione <code>-t</code>/<code>--target-release</code>. | # 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>. | # 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>. | ||
# 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 | # 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 -t experimental install nomepacchetto</code> | ||
== Testing con pacchetti non-free e repository deb-multimedia == | == Testing con pacchetti non-free e repository deb-multimedia == | ||
| Riga 358: | Riga 369: | ||
=== sources.list === | === sources.list === | ||
Abilitiamo anche le sezioni ''contrib'' e ''non-free'': | Abilitiamo anche le sezioni ''contrib'' e ''non-free'': | ||
# Debian testing - sicurezza | # Debian testing | ||
deb | deb {{APT-mirror}} testing main contrib non-free | ||
# repository NON ufficiali - multimedia | # Debian testing - sicurezza | ||
deb http://www.deb-multimedia.org testing main non-free | deb {{APT-mirror|security}} testing-security main contrib non-free | ||
# repository NON ufficiali - multimedia | |||
deb http://www.deb-multimedia.org testing main non-free | |||
Senza altre impostazioni, tutti i repository avrebbero una priorità di 500, e pertanto di default verrebbero sempre installati quelli solitamente più aggiornati di ''deb-multimedia'', ogni volta che è possibile. Questo comportamento non è affatto desiderabile, e anzi può compromettere la stabilità del sistema. | 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. | ||
| Riga 412: | Riga 422: | ||
|Verificata_da = | |Verificata_da = | ||
: [[Utente:Wtf|Wtf]] | : [[Utente:Wtf|Wtf]] | ||
: [[Utente:HAL 9000|HAL 9000]] | : [[Utente:HAL 9000|HAL 9000]] 15:58, 3 ago 2019 (CEST) | ||
|Numero_revisori = 2 | |Numero_revisori = 2 | ||
}} | }} | ||
[[Categoria:Apt]][[Categoria:E-zine]][[Categoria:Repository ufficiali]] | [[Categoria:Apt]][[Categoria:E-zine]][[Categoria:Repository ufficiali]] | ||