Translation(s): English - Español - Italiano - Русский - 简体中文


Informazioni generali sulle preferenze per APT (APT-preferences)

APT (Advanced Package Tool, strumento avanzato per pacchetti) viene configurato da diverse risorse, incluse

... in aggiunta alle preferenze di APT discusse in seguito. Le preferenze di APT possono essere utilizzate per vari compiti; sfortunatamente solo il pinning viene attualmente discusso in questa pagina. Per informazioni più dettagliate e autorevoli riguardanti:

Configurazione delle preferenze di APT

Come il resto delle risorse di configurazione di APT, le preferenze di APT vengono configurate scrivendo informazioni in file in uno di due modi:

  1. Il più nuovo, più facilmente estensibile e preferito: scrivere più file in un'unica directory. Per le preferenze di APT tale directory è /etc/apt/preferences.d/

  2. Il vecchio modo deprecato: scrivere tutte le informazioni sulle preferenze di APT in un unico file, /etc/apt/preferences

A differenze di altre risorse di configurazione per APT, le preferenze di APT sono strettamente collegate alle fonti per APT, perciò è necessario trattare anche quelle. Le fonti di APT sono configurate in modo simile in uno di due modi:

  1. Il più nuovo, più facilmente estensibile e preferito: scrivere più file in /etc/apt/sources.list.d/

  2. Il vecchio modo deprecato: scrivere tutte le informazioni su fonti/repository in /etc/apt/sources.list

Tuttavia anche il pinning utilizza il concetto di rilascio target, che è tipicamente impostato usando APT-conf ... che è (incredibile, vero?) in modo simile configurato in uno di due modi:

  1. Il più nuovo, più facilmente estensibile e preferito: scrivere più file in /etc/apt/apt.conf.d/

  2. Il vecchio modo deprecato: scrivere tutte le informazioni sui rilasci target in /etc/apt/conf

Da ultimo è necessario comprendere che tutto quanto può essere specificato o sovrascritto usando varie righe di comando, strumenti con interfacce utente testuali o grafiche come apt-get e aptitude.

Pinning

<!> Quando si usa il pinning è necessario assicurarsi da soli della compatibilità dei pacchetti in quanto Debian non la garantisce. Notare che l'uso di apt-pinning è del tutto opzionale e Debian non incoraggia il suo utilizzo senza una attenta valutazione.

Il pinning permette di richiamare specifici pacchetti da una versione (es., stable, testing, unstable) senza eseguire tutto il sistema con quella versione. Il pinning viene solitamente (ma non sempre) utilizzato pe richiamare uno o più pacchetti da una versione successiva, per potere avere accesso a versioni più aggiornate di pacchetti: unstable è considerata successiva a testing che è successiva a stable. Tuttavia, i pacchetti hanno dipendenze che possono andare in conflitto, perciò il pinning (cioè il non richiamare tutti i pacchetti da un'unica versione) può causare problemi. Pertanto, prima di considerare il pinning, controllare se per la versione del pacchetto che si desidera è stato fatto un backport per la versione da cui si stanno già prelevando i pacchetti.

/etc/apt/sources.list

#### testing #########
deb http://ftp.us.debian.org/debian testing main contrib non-free

#### unstable #########
deb http://ftp.us.debian.org/debian unstable main contrib non-free

In questo esempio si preleva da testing e unstable. Si potrebbe, ovviamente, modificarlo per attingere da stable.

/etc/apt/preferences

Il file 'preferences' è dove si configura il reale pinning. Ecco un esempio:

Package: *
Pin: release a=testing
Pin-Priority: 900

Package: *
Pin: release a=unstable
Pin-Priority: 800

Package è impostato su qualsiasi pacchetto, come specificato dall'asterisco. Pin determina la versione (testing e unstable). Pin-Priority indica il livello di priorità. L'impostazione standard di 'apt-get' è qualcosa sulla falsariga di "vince la versione più recente del pacchetto". Quanto sopra ristruttura questa priorità in modo che i pacchetti in testing abbiano una maggiore priorità.

Installare da unstable

Supponiamo che si stia usando testing e si voglia provare enlightenment da unstable. Ci sono fondamentalmente due metodi per installare:

 # apt-get install enlightenment/unstable
 # apt-get -t unstable install enlightenment

Nel primo caso non si tenterà di aggiornare nessun pacchetto sul proprio sistema, quindi se non vengono trovate le specifiche dipendenze l'installazione avrà esito negativo. Il secondo metodo proverà ad installare o aggiornare le dipendenze. Naturalmente, dato l'esempio precedente, 'apt-get' chiederà prima di procedere.

Note di Joshua Rodman

Personalmente, ho trovato problematica la configurazione di un pin con priorità più elevata per testing e una priorità più bassa per unstable. A volte, i pacchetti di testing dipendono da altri che non sono attualmente in testing (forse rappresenta un piccolo problema in testing), e questo fa sì che i pacchetti siano prelevati automaticamente da unstable. Nel periodo precedente al processo di stabilizzazione di testing per il rilascio di Woody questo ha fatto sì che io mi trovassi installati più di 100 pacchetti da unstable senza nemmeno rendermene conto.

Di conseguenza uso un approccio più prudente ad una distribuzione mista, del tipo "solo se io dico così", con un file come questo:

Package: *
Pin: release a=testing
Pin-Priority: 900

Package: *
Pin: release o=Debian
Pin-Priority: -10

Così tutti i pacchetti Debian sono impostati con priorità -10, mentre testing riceve un bonus di 900 punti. Questo richiama i comportamenti:

Dal manuale di apt_preferences(5)

  500 < P <=990 :
        sarà installata una versione a meno che non vi è una versione
        disponibile appartenente ad un certo rilascio o la versione
        installata è più recente 
  [...]
  P < 0 :
         impedisce che venga installata la versione 

Si noti che una priorità superiore a 1000 permetterà anche il downgrade senza considerare la versione del pacchetto prioritario. Questo significa che è possibile utilizzare una priorità 1001 per una fonte stabile se si desidera effettuare un downgrade alla versione stable dei pacchetti installati (diciamo da testing) sul sistema. Questo non è raccomandato a meno che il numero di modifiche non sia minimo.

L'installazione di pacchetti con apt-get install nomepacchetto/unstable e apt-get install -t unstable nomepacchetto funzionerà ancora, ma i pacchetti da unstable potranno essere installati solo con questi comandi.

Note di ZugSchlus

Disclaimer

Questa pagina è stata scritta da ZugSchlus, che non coglie neanche lontanamente il concetto di pinning. Perciò si prega di intendere letteralmente le parole "probabilmente", "deve essere verificata" e simili, e documentare qui le proprie scoperte (anche se sono "questa pagina è corretta" o "questa pagina è sbagliata", eventualmente "questa pagina è sbagliata perché...").

Descrizione del processo di selezione dei pacchetti

-->Ecco come qualcuno pensa che dovrebbe essere.

ToDo: Necessita di essere verificato

Esempi di un file /etc/apt/preferences

Esempio 1

Package: *
Pin: release o=Debian,a=testing
Pin-Priority: 900

Package: *
Pin: release o=Debian,a=unstable
Pin-Priority: 300

Package: *
Pin: release o=Debian
Pin-Priority: -1

Mancante: Descrivere cosa fa questo file di preferenze.

ZugSchlus prova a spiegare:

Problema: Questo pin si comporta in modo diverso a seconda di quale versione è impostata in altre parti della configurazione di apt. Quindi questo esempio non può davvero essere documentato senza aggiungere ulteriori informazioni. Un pacchetto senza pinning facente parte della versione principale ha una priorità predefinita di 990, mentre altri pacchetti senza pinning hanno una priorità predefinita di 500.

Esempio 2

Obiettivo: Prelevare dpatch da experimental in un sistema unstable.

Una possibile (e non del tutto corretta) soluzione:

Package: dpatch
Pin: release o=Debian,a=experimental
Pin-Priority: 450

Esempio 3

Da Mihamina rakotomandimby

Supponendo di avere un deposito personale dove è presente una personale versione di Postfix e di volere che Apt la preferisca a quella ufficiale.

È possibile impostare le preferenze tramite origin

Package: *
Pin: origin www.rktmb.org
Pin-Priority: 610

Package: *
Pin: origin ftp.fr.debian.org
Pin-Priority: 600

Individuazione degli errori

apt-cache policy package fornisce informazioni sul processo di selezione. Purtroppo non è ampiamente noto cosa significhi l'output. Il seguente è un tentativo di interpretarlo:

 $ apt-cache policy exim4-daemon-light
 exim4-daemon-light
  Installed: 4.50-1
  Candidate: 4.50-1
  Package Pin: (not found)
  Version Table:
      4.50-4 555
        500 http://mirror sid/main Packages
  *** 4.50-1 555
        100 /var/lib/dpkg/status
      4.44-2 555
        500 http://mirror sarge/main Packages

La priorità di ogni versione/ubicazione è il numero a sinistra di esse; in questo caso, 500, 100 e 500. Il numero alla destra della versione mostra la priorità di pin effettiva assegnata al pacchetto.

Nota da Ryan B.

Se ci si chiede quali siano le opzioni per le preferenze del file release, in base a questo collegamento: http://www.debian.org/doc/manuals/repository-howto/repository-howto

scopriamo che:

Archive: archivio

Component: componente

Origin: Propria azienda

Label: Repository Debian della propria azienda

Architecture: architettura

Perciò la riga: "Pin: release a=testing" troverà valori di archivio nel file release chiamato "testing".

Nota da Georgios Zarkadas

Ho scoperto che usare un valore più alto di 500 per il pin di testing/unstable fa sì che apt-get upgrade cerchi di aggiornare tutti i pacchetti con una versione più nuova a testing/unstable anche quando avevo stable con un valore di pin che era più alto di quello di testing/unstable.

In seguito, guardando il risultato di apt-cache policy <un-qualche-pacchetto> per alcuni dei pacchetti che apt-get upgrade riteneva di dover aggiornare, sono arrivato alla conclusione che, se ci sono diverse versioni con candidati con pin a 500 o più, allora il valore di pin viene preso in considerazione dopo il numero di versione. Perciò viene scelta la versione più alta con il pin di peso più alto tra i candidati di quella (e solo quella) versione.

Per esempio, avendo stable con pin a 700, testing a 650 e unstable a 600:

root@freedom:/etc/apt# apt-cache policy deborphan
deborphan:
  Εγκατεστημένα: 1.7.28.3+squeeze1
  Υποψήφιο: 1.7.28.5
  Πίνακας Έκδοσης:
     1.7.28.5 0
        650 http://ftp.gr.debian.org/debian/ wheezy/main amd64 Packages
        600 http://ftp.gr.debian.org/debian/ sid/main amd64 Packages
 *** 1.7.28.3+squeeze1 0
        500 http://ftp.gr.debian.org/debian/ squeeze-proposed-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.7.28.3 0
        500 cdrom://[Debian GNU/Linux 6.0.1a _Squeeze_ - Official amd64 DVD Binary-1 20110322-16:05]/ squeeze/main amd64 Packages
        700 http://ftp.gr.debian.org/debian/ squeeze/main amd64 Packages

Dato che il motivo per cui uso sorgenti multiple e i valori di pin è di poter occasionalmente installare un pacchetto da testing o unstable e non aggiornare tutti i pacchetti, usare valori di pin per testing / unstable uguali o maggiori di 500 è chiaramente un metodo non adatto per farlo.

Ho tuttavia scoperto che usando un valore minore di 500 per testing/unstable ha l'effetto desiderato. Per esempio, rimuovendo il pin di stable e impostando testing a 450 e unstable a 400:

root@freedom:/etc/apt# apt-cache policy deborphan
deborphan:
  Εγκατεστημένα: 1.7.28.3+squeeze1
  Υποψήφιο: 1.7.28.3+squeeze1
  Πίνακας Έκδοσης:
     1.7.28.5 0
        450 http://ftp.gr.debian.org/debian/ wheezy/main amd64 Packages
        400 http://ftp.gr.debian.org/debian/ sid/main amd64 Packages
 *** 1.7.28.3+squeeze1 0
        500 http://ftp.gr.debian.org/debian/ squeeze-proposed-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.7.28.3 0
        500 cdrom://[Debian GNU/Linux 6.0.1a _Squeeze_ - Official amd64 DVD Binary-1 20110322-16:05]/ squeeze/main amd64 Packages
        500 http://ftp.gr.debian.org/debian/ squeeze/main amd64 Packages

Nota da Dmitriy Matrosov

Penso che la conclusione a cui arriva Georgios Zarkadas nella (nota precedente) riguardo il "pinning considerato da apt dopo il numero di versione":

Sono arrivato alla conclusione che, se ci sono diverse versioni con candidati con pin a 500 o più, allora il valore di pin viene preso in considerazione '''dopo''' il numero di versione.

sia sbagliata. Guardando nuovamente l'esempio da lui presentato:

root@freedom:/etc/apt# apt-cache policy deborphan
deborphan:
  Εγκατεστημένα: 1.7.28.3+squeeze1
  Υποψήφιο: 1.7.28.5
  Πίνακας Έκδοσης:
     1.7.28.5 0
        650 http://ftp.gr.debian.org/debian/ wheezy/main amd64 Packages
        600 http://ftp.gr.debian.org/debian/ sid/main amd64 Packages
 *** 1.7.28.3+squeeze1 0
        500 http://ftp.gr.debian.org/debian/ squeeze-proposed-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.7.28.3 0
        500 cdrom://[Debian GNU/Linux 6.0.1a _Squeeze_ - Official amd64 DVD Binary-1 20110322-16:05]/ squeeze/main amd64 Packages
        700 http://ftp.gr.debian.org/debian/ squeeze/main amd64 Packages

Come prima cosa, apt cerca di aggiornare da stable (squeeze/main) dato che stable ha la priorità più alta (700), ma vede che il pacchetto installato è più recente:

sgf@shilvana:~$ dpkg --compare-versions 1.7.28.3 lt '1.7.28.3+squeeze1' ; echo $?
0

e la priorità 700 non è sufficiente per retrocedere ad una versione precedente. Perciò continua a cercare tra le versioni candidate. Ora apt cerca di aggiornare da testing (wheezy/main) e vede che la versione in testing è più recente:

sgf@shilvana:~$ dpkg --compare-versions '1.7.28.3+squeeze1' lt 1.7.28.5 ; echo $?
0

Perciò questa versione (da testing) diventa una candidata.

Quindi, per poter aggiornare da stable (come vuole fare Georgios Zarkadas), è necessario avere il pacchetto con una versione <= di quella che si trova in stable.

Riferimenti