Translation(s): English - Italiano - 简体中文

Questo articolo cerca di spiegare come utilizzare le preferenze di APT. Al momento è documentato solo il pinning.

Pinning

Prima di prendere in considerazione il 'pinning', si può voler verificare se il pacchetto desiderato è stato inserito nei backport della propria versione.

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

Il Pinning consente l'esecuzione di alcuni pacchetti da una versione (stable, testing, unstable) senza la necessità di aggiornare interamente il proprio sistema. Tuttavia, il prelievo di pacchetti da distribuzioni "successive" tende a portarsi dietro anche delle librerie, il che potrebbe concludersi con un sistema che ha gli svantaggi di stable (software vecchio), gli svantaggi di unstable/testing (bug, il supporto di sicurezza non è ottimale come per stable) senza i vantaggi di nessuna delle due.

Di base il pinning coinvolge due file, /etc/apt/sources.list e /etc/apt/preferences.

Un ulteriore ruolo è svolto dalla versione principale, che può essere impostata in apt.conf (o un file in /etc/apt/conf.d/... e tramite la riga di comando di apt.

/etc/apt/sources.list

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

 #### unstable #########
 deb ftp://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à.

Si faccia riferimento anche alla pagina di manuale di apt_preferences(5).

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

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 GeorgiosZarkadas

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