Repository & pinning

I repository
Arrow left.png

Introduzione ai repository

Repository ufficiali di Debian

Repository esterni

Extra

Arrow right.png



Repository e Pinning
Banner e-zine.png
La prima e-zine italiana sul mondo Debian

Una rapida panoramica su uno dei temi più importanti in Debian: il funzionamento e la configurazione dei repository, ed il pinning ovvero la possibilità di attingere dai repository dei diversi rami, cercando di mantenere il sistema più stabile possibile.

Dopo aver installato una Debian nasce il bisogno di aggiungere nuovi programmi e allo stesso tempo tenerla costantemente aggiornata. Per questo scopo Debian dispone di un tool potentissimo: apt (Advanced Packaging Tool), con numerosi strumenti sia da riga di comando (la shell), come dpkg, apt-get, aptitude, dselect, wajig, sia per mezzo di interfacce grafiche come synaptic, aptitude, adept, gjig ed altri. Per comprendere appieno tutto il meccanismo delle installazioni e degli aggiornamenti bisogna conoscere com'è strutturata una Debian. Questo articolo vuole essere un'introduzione alla comprensione della struttura per la gestione dei 20.000 ed oltre pacchetti che Debian offre. Per approfondimenti consultare le ricche pagine di documentazione che accompagnano Debian come debian-reference-it, debian-faq-it, etc.

Tratto dalla e-zine di Debianizzati.org

Link agli articoli:

Repository e Pinning

Introduzione

Come molti sapranno, esistono tre distribuzioni di Debian (chiamate anche release):

  1. Debian stable, attualmente Wheezy;
  2. Debian testing, attualmente Jessie;
  3. Debian unstable, attualmente (e sempre, un nome fisso) Sid.

Il software della stable non viene aggiornato, eccezion fatta per gli aggiornamenti della sicurezza; il software della testing e della unstable viene al contrario aggiornato frequentemente, con una maggiore frequenza per la unstable. Oltre queste tre, ci sarebbero anche la oldstable (la vecchia stable, precedente all’attuale stable) e la experimental che non è una versione completa e funzionante di Debian, ma solo un repository contenente vario software in fase di progettazione, da sperimentare o altamente instabile, dal quale si può attingere dalle altre versioni ma a proprio rischio.

Spesso accade che utilizzando la testing o ancor di più la stable si voglia del software più nuovo rispetto a quello in dotazione; o che al contrario, utilizzando la testing o ancor di più la unstable si voglia del software più stabile rispetto a quello in dotazione. Qui entra in gioco il pinning dei repository, o meglio “tra i repository”, che permette di installare con semplicità del software appartenente a una distribuzione di Debian diversa da quella in uso o anche solo appartenente alla stessa distribuzione, ma proveniente da un altro repository.Tutto ciò riducendo al minimo (posto di sapere quel che si fa) il rischio di creare problemi nel sistema e nel gestore dei pacchetti.

  ATTENZIONE
Installare pacchetti provenienti da distribuzioni e/o fonti differenti è sempre e comunque fonte di possibili rischi, anche se piccoli


Prima di procedere nella descrizione operativa del pinning è fondamentale capire come gestisce la priorità dei pacchetti APT e sapere che:

  • Col termine distribuzione si intendono stable, testing e unstable. Ciascuna distribuzione ha un suo singolo repository (fonte) principale (due se si conteggia anche l'eventuale repository dedicato agli aggiornamenti di sicurezza) che è quello automaticamente dichiarato dall'installer di debian, ma si tenga presente che ogni distribuzione può avere più fonti sia ufficiali che non ufficiali.
  • Col termine fonti si intendono genericamente i repository, ufficiali (es. stable, testing, unstable e backports) o meno (es. deb-multimedia), che forniscono pacchetti relativi ad una o più distribuzioni. Ogni fonte può avere più copie di se stesso (mirrors).
  Importante
Il pinning è uno strumento per regolare la priorità in base al numero di versione dei pacchetti, e non alla fonte di provenienza. Questo significa che non è possibile discriminare tra due pacchetti aventi lo stesso numero di versione e provenienti da due repository differenti, ovvero in caso di pari versione ad essere installato sarà la versione proveniente dal repository elencato per primo nel file sources.list.


Priorità come punteggio

Il concetto di priorità viene gestito attraverso l'assegnazione di un punteggio ai vari pacchetti, sia installati che ancora da installare. Valgono le seguenti regole:

  • priorità 100 alla versione dei pacchetti già installati.
  • priorità 500 alle versioni che non sono installate e non appartengono alla distribuzione obiettivo, dove con quest'ultimo termine si deve intendere "Default Release", "Target Release". Si noti per alcuni repository (come backports) in realtà la priorità predefinita di tali pacchetti risulta essere 100 e non 500 (vedasi manuale per maggiori informazioni).
  • priorità 990 alle versioni che non sono installate e appartengono alla distribuzione obiettivo.

Piccolo esempio teorico. Si supponga quanto segue:

  • si desidera installare il pacchetto "vattelapesca" appartenente alla propria distribuzione obiettivo, cioè quella che si è installata (si supponga testing);
  • il suddetto pacchetto è presente in tre fonti, repoA, repoB, repoC tutte correttamente specificante nel file source.list;
  • tutti i pacchetti presenti in repoA appartengono alla distribuzione obiettivo (testing in questo esempio), in repoB e repoC sono contenuti pacchetti appartenenti ad un'altra distribuzione (ad esempio unstable e stable rispettivamente);
  • la versione di "vattelapesca" in repoA è la 1.4, in repoB la 2.0 e in in repoC la 1.1;
  • nel sistema è installata la versione 1.3 di "vattelapesca";
  • non esiste un file preferences o comunque non è stata specificata una priorità per nessuna delle tre distribuzioni considerate;
  • non è stato dichiarato il parametro Default Release in un eventuale file apt.conf, ovvero non è stata esplicitamente definita una distribuzione obiettivo.

Nel momento in cui l'utente esegue il comando apt-get install vattelapesca saranno assegnati i seguenti punteggi:

  • 500 a "vattelapesca" presente in repoC;
  • 500 a "vattelapesca" presente in repoB;
  • 500 a "vattelapesca" presente in repoA;

Tutti e tre i pacchetti hanno lo stesso punteggio, ma il pacchetto proveniente da C viene immediatamente scartato perché implicherebbe retrocessione dello stesso (downgrade, il significato delle varie fascie di punteggio sarà spiegato poco più avanti). A questo punto APT sceglierà tra repoA e repoB in base ad un altro criterio, la versione, quindi ad essere installato sarà il pacchetto proveniente da repoB e non da repoA come desiderato. Il problema evidentemente non può che esplodere quando si esegue il comando apt-get upgrade (o peggio apt-get dist-upgrade), cioè quando si tenta di aggiornare tutti i pacchetti di sistema.

La soluzione è, come facilmente intuibile, quella di assegnare manualmente un punteggio ai vari pacchetti, singolarmente o raggruppandoli. Prima però è necessario capire il significato dei vari punteggi (pin). Nel seguito si indicherà col termine "candidato" il pacchetto o gruppo di pacchetti proveniente dalla generica fonte dichiarata nel file sources.list.

  • Pin minore di 0 (negativo), l’installazione del candidato è impedita a priori (salvo apposito comando).
  • Pin compreso tra 1 e 99, il candidato sarà installato solo se sono verificate entrambe le seguenti due condizioni: primo non esistono candidati appartenenti ad altre distribuzioni, secondo nel sistema non è già installata una versione (anche inferiore) del candidato.
  • Pin compreso tra 100 e 499, il candidato sarà installato solo se non esistono candidati appartenenti ad altre distribuzioni e se la versione eventualmente già installata non è superiore a quella del candidato. Se per esempio il pacchetto "vattelapesca" ha pin 400 ed è presente su due fonti (posto ovviamente di aver dichiarato entrambe nel solito sources.list) e ciascuna fonte appartiene ad una distribuzione differente, come stable e testing, allora sarà impossibile installare il suddetto pacchetto, a prescindere dal numero di versione; diversamente se le due fonti appartenessero alla stessa distribuzione allora il pacchetto potrebbe teoricamente essere installato. (NOTA, l'esempio fatto è strettamente teorico e non verificato praticamente).
  • Pin compreso tra 500 e 989, il candidato sarà installato solo se non esistono candidati appartenenti alla distribuzione obiettivo e se la versione eventualmente già installata non è superiore a quella del candidato. Si noti che il semplice fatto di aver installato una certa distribuzione, per esempio testing, non significa aver definito la distribuzione obiettivo, che può essere solo definita manualmente dall'utente (il come sarà spiegato nella discussione del file apt.conf).
  • Pin compreso tra 990 e 999, il candidato sarà installato solo se non esistono altri candidati con pin maggiore e se la versione eventualmente già installata non è superiore a quella del candidato.
  • Pin 1000 o superiore, il candidato sarà installato se non esistono altri candidati con pin maggiore, è quindi possibile la retrocessione di versione (downgrade) se la versione eventualmente già installata è superiore a quella del candidato. Es. è possibile installare la versione 1.1 di un pacchetto anche se ad essere già installata è la 1.2 o superiore.
  Nota
  • Gli intervalli sopra citati sono presi tali e quali dal manuale di apt_preferences, tuttavia a volte si è osservato che i limiti funzionano come dovrebbero se traslati in alto di una unità, ad esempio l'ultimo intervallo potrebbe partire da 1001 invece che da 1000.
  • APT può derogare alle regole generali sopra esposte in casi particolari per soddisfare le varie dipendenze dei pacchetti.


/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 Aptitude per alcuni brevi esempi contenenti alcui dei parametri più comuni. Per quanto riguarda il pinning l'unico parametro strettamente di rilievo è:

APT::Default-Release "distribuzione_voluta";

che equivale alla dichiarazione in riga di comando dell'opzione -t distribuzione_voluta sia in Apt-Get che Aptitude. Tale dichiarazione attribuisce priorità 990 a tutti i pacchetti appartenenti alla distribuzione specificata.

  ATTENZIONE
  • Tale priorità si applica alla distribuzione 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.
  • Per quanto riguarda tutti i pacchetti della release target 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


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 apt-get install pacchetto -t distribuzione_taldeitali sorpassa qualunque distribuzione obiettivo (Default-Release) dichiarata nel file apt.conf.
  • Comandi del tipo apt-get install pacchetto/distribuzione_taldeitali non cambiano la target release, ma si limitano a dire di prelevare lo specifico pacchetto dalla distribuzione indicata invece che da quella predefinita. Questo implica che le dipendenze continueranno ad essere risolte in base alla distribuzione obiettivo eventualmente specificata in apt.conf e/o in base al file preferences e/o in accordo all'algoritmo predefinito.
  • Definire una distribuzione obiettivo in apt.conf è equivalente a dichiarare in preferences (si veda la prossima sezione) quanto segue
Package: *
Pin: release a=distribuzione_voluta
Pin-Priority: 990
  • Qualora si sia definita una distribuzione obiettivo in apt.conf allora quasiasi dichiarazione in preferences riguardante tutti i pacchetti di una certa distribuzione sarà ignorata, ad esempio definire
Package: *
Pin: release a=testing
Pin-Priority: 1000
è del tutto inutile se poi si usa l'opzione -t testing. Non è invece inutile una dichiarazione del seguente tipo:
Package: specifico pacchetto o espressione regolare
Pin: release a=testing
Pin-Priority: 1000
  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)


/etc/apt/preferences

Questo è il file dove è possibile definire tutte le priorità che si vogliono, fermo restando quanto detto nella sezione dedicata ad apt.conf. La sintassi generale è la seguente:

Package: nome pacchetto o espressione regolare
Pin: parametro da usare per identificare la versione desiderata
Pin-Priority: numero

Un paio di esempi del tutto arbitrari:

Package: vlc
Pin: release a=testing
Pin-Priority: 991
 
Package: virtualbox4*
Pin: Release o=Oracle Corporation
Pin-Priority: 780

Nel primo esempio si è definito il pinning per il pacchetto di nome "vlc", richiedendo che le versioni appartenenti alla distribuzione 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.

Il pinning può essere orientato ai campi "Suite", "Origin", "Label" e "Codename" del file "Release" di un certo repository (si veda inizio pagina), nonché all'indirizzo del repository stesso. Si noti che per archivi personali e/o non ufficiali può non essere presente (purtroppo) un file "Release". È utile infine evidenziare un paragrafo del manuale di apt_preferences:

  Importante
Se almeno un record in forma specifica corrisponde ad una versione di pacchetto disponibile, allora il primo di questi record determina la priorità della versione del pacchetto. In caso contrario, se almeno un record in forma generica corrisponde ad una versione di pacchetto disponibile, allora il primo di questi record determina la priorità della versione del pacchetto.


  Suggerimento
Specificare nel file sources.list sempre per primi il o i repository principali della distribuzione obiettivo.


  File multipli
È possibile creare più file di nome arbitrario in /etc/apt/apt.preferences.d/ invece di creare un unico file di nome preferences, (si veda il manuale).


Blocco/retrocessione di pacchetti

Il file preferences come già accennato può essere usato per bloccare e/o retrocedere (downgrade) uno o più pacchetti (al limite tutti); in entrambi i casi è necessario definire un pin maggiore di 1000 per il pacchetto desiderato. Se per esempio nel file preferences fosse presente un record come il seguente:

Package: nome_pacchetto
Pin: version 1.0.1
Pin-Priority: 1001

Si avrebbero i seguenti due casi:

  1. Se nel sistema non esiste una versione del suddetto pacchetto oppure se già installato la sua versione è più vecchia di 1.0.1, allora il pacchetto viene aggiornato normalmente, ma una volta terminata l'installazione questo pacchetto non verrà mai più aggiornato.
  2. Se il pacchetto è già stato installato e la sua versione è più recente di 1.0.1 allora il pacchetto presente nel sistema viene disinstallato e sostituito con quello avente versione 1.0.1. Terminata l'installazione il pacchetto non verrà mai più aggiornato.

Per permettere nuovamente l'aggiornamento del pacchetto è necessario o ridurre il pin sotto 1000 o eliminare del tutto il record.

Retrocedere l'intero sistema

Nella maggior parte dei casi (o forse sempre) questa È UNA FOLLIA, tuttavia per motivazioni puramente didattiche si mostra come fare. In primis è necessario eliminare, se presente, dal file apt.conf il parametro default-release, dopo di che aggiungere al file preferences un record come il seguente (sostituire a "stable" la versione desiderata, ad esempio "testing" se si vuole retrocedere da "unstable").

Package: *
Pin: release a=stable
Pin-Priority: 1001

A questo punto dovrebbe essere sufficiente digitare da terminale:

# apt-get dist-upgrade

oppure

# aptitude full-upgrade

Esempi

01 - Release pura

Sebbene non sia necessario definire il pinning nel caso ci si limiti ad usare i repository ufficiali della propria release di debian, può comunque essere prudente definire un file apt.conf. Se infatti si dovesse decidere di aggiungere altri repository in seguito non si rischierebbe il disastro nel caso in cui ci si dimenticasse di definire correttamente un pinning. Nel caso della stable il succitato file potrebbe essere definito come segue:

APT
{
        Default-Release "stable";
        Cache-Limit 24000000;
        Get
        {
                AllowUnauthenticated 1;
                AutomaticRemove "true";
                Fix-Broken "true";
                Purge "true";
                Show-Upgraded "true";
        }
}
Aptitude
{
        Autoclean-After-Update "true";
        Auto-Fix-Broken "true";
        Purge-Unused "true";
}

Se invece della stable si volesse usare una testing o unstable pura basterebbe correggere opportunamente la riga in cui è dichiarato il parametro Default-Release.

02 - Stable con backports

Si supponga di voler usare tutti i pacchetti della stable, con l'eccezione di quelli relativi a libre office e iceweasel.

apt.conf

APT
{
        Default-Release "stable";
        Cache-Limit 36000000;
        Get
        {
                AllowUnauthenticated 1;
                AutomaticRemove "true";
                Fix-Broken "true";
                Purge "true";
                Show-Upgraded "true";
        }
}
Aptitude
{
        Autoclean-After-Update "true";
        Auto-Fix-Broken "true";
        Purge-Unused "true";
}

preferences


Package: iceweasel*
Pin: release a=stable-backports
Pin-Priority: 992

Package: libreoffice*
Pin: release a=stable-backports
Pin-Priority: 992

03 - Testing con unstable

La distribuzione principale sia testing, quella secondaria unstable. Lo scopo è far sì che in automatico vengano recuperati da unstable tutti i pacchetti che non sono disponibili in testing.

sources.list

deb http://ftp.it.debian.org/debian/ testing main contrib non-free
deb http://security.debian.org/ testing/updates main contrib non-free
deb http://ftp.de.debian.org/debian unstable main contrib non-free

apt.conf

APT
{
        Default-Release "testing";
        Cache-Limit 48000000;
        Get
        {
                AllowUnauthenticated 1;
                AutomaticRemove "true";
                Fix-Broken "true";
                Purge "true";
                Show-Upgraded "true";
        }
}
Aptitude
{
        Autoclean-After-Update "true";
        Auto-Fix-Broken "true";
        Purge-Unused "true";
}

preferences


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

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

Conseguenze

Usando le azioni install e upgrade senza specificare l'opzione -t unstable si installano/aggiornano pacchetti prelevando le versioni da testing, a meno che un pacchetto sia presente solo in unstable, nel qual caso sarà prelevato da lì. Le dipendenze saranno risolte se possibile usando testing, altrimenti usando unstable.

Digitando apt-get install vattelapesca -t unstable si installerà la versione "vattelapesca" appartenente ad unstable, così come le sue dipendenze. Si noti che in questo caso successivi aggiornamenti tramite comandi del tipo apt-get upgrade o apt-get dist-upgrade non produrranno alcun aggiornamento da unstable del pacchetto "vattelapesca" se questo è anche presente in testing; in tal caso l'unica possibilità di aggiornare "vattelapesca" è digitare nuovamente apt-get install vattelapesca -t unstable (o aspettare pazientemente che la versione di testing superi quella installata).

L'installazione di tutti i pacchetti provenienti da distribuzioni differenti da testing o unstable è completamente impedita, anche nel caso si aggiungessero repository relativi ad altre distribuzioni.

04 - Testing con deb-multimedia

Sia testing l'unica distribuzione 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.

  Nota
Questo esempio non permette di retrocedere automaticamente pacchetti già installati da deb-multimedia.


sources.list

deb http://ftp.it.debian.org/debian/ testing main contrib non-free
deb http://security.debian.org/ testing/updates main contrib non-free
deb http://www.deb-multimedia.org testing main non-free

apt.conf

APT
{
        Cache-Limit 48000000;
        Get
        {
                AllowUnauthenticated 1;
                AutomaticRemove "true";
                Fix-Broken "true";
                Purge "true";
                Show-Upgraded "true";
        }
}
Aptitude
{
        Autoclean-After-Update "true";
        Auto-Fix-Broken "true";
        Purge-Unused "true";
}

preferences


Package: *
Pin: Release o=Unofficial Multimedia Packages
Pin-Priority: 101

Package: *
Pin: Release a=Testing
Pin-Priority: 990

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

Osservazioni

Poiché entrambe le fonti, principale e deb-multimedia, appartengono alla distribuzione 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 apt.conf una distribuzione obiettivo e definendo in preferences 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 distribuzione obiettivo in apt.conf risultando perfino inutile definire un file preferences, visto che come già detto di norma i candidati di deb-multimedia hanno numero di versione maggiore di queli del repository principale.

In ultimo si fa semplicemente osservare che l'utilizzo dell'opzione -t in questo caso è inutile, visto che si lavora per ipotesi con una sola distribuzione.

L'installazione di tutti i pacchetti provenienti da distribuzioni differenti da testing è completamente impedita, anche nel caso si aggiungessero repository relativi ad altre distribuzioni.

05

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

Assicuriamoci di essere l'utente root e procediamo.

Per prima cosa editiamo il file /etc/apt/sources.list ed inseriamo gli archivi dei pacchetti Debian che utilizzeremo, per esempio:

### Debian Ufficiale -- Testing
deb http://ftp.it.debian.org/debian/ testing main contrib non-free

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

### Debian Ufficiale -- Sid
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 sid main non-free

Configurare apt

A questo punto dobbiamo preparare due file normalmente non presenti sulla nostra debianbox: si tratta dei file /etc/apt/preferences e /etc/apt/apt.conf. 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 apt.conf

Ora creiamo il file /etc/apt/apt-conf

# touch /etc/apt/apt.conf

ed editiamolo inserendo quanto segue:

APT::Cache-Limit 15000000;
Apt::Get::Purge;
APT::Clean-Installed;
APT::Get::Fix-Broken;
APT::Get::Fix-Missing;
APT::Get::Show-Upgraded "true";

Il file preferences

Creiamo il file /etc/apt/preferences:

# touch /etc/apt/preferences

ed editiamolo col nostro editor di fiducia e inseriamo queste direttive:

Package: *
Pin: release o=Unofficial Multimedia Packages
Pin-Priority: 992

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

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

Package: *
Pin: release a=experimental
Pin-Priority: 750

Facciamo l'update del database dei pacchetti:

# apt-get update

D'ora in avanti avremo due possibilità per installare un nuovo pacchetto: il metodo che usiamo di solito e cioè:

# apt-get install nome_pacchetto

che utilizzerà pacchetti proveniente dalla versione impostata come Default-Release in apt.conf, oppure il comando

# apt-get install -t versione_di_debian nome_pacchetto

che provvederà a installare il pacchetto da noi richiesto per la versione specificata (versione_debian), risolvendo automaticamente le dipendenze.

Comandi utili

È possibile visualizzare l'elenco delle priorità relative a tutti i repository e pacchetti dichiarati col seguente comando:

# apt-cache policy

Se si volesse visualizzare solo la priorità per un singolo singolo pacchetto, ad esempio nano, si può digitare:

# apt-cache policy nano


_________________________________________________________________________________________________________________________________________________________



PINNING

Abbiamo visto come poter avere una Debian Stable, Testing o Unstable adattando i repository all'uopo. Però, usando una Stable o una Testing potrebbe nascere l'esigenza di bloccare un pacchetto o volerlo aggiornare ad una versione che si trova in un ramo superiore senza compromettere la stabilità e la funzionalità della versione che si sta utilizzando o addirittura fare un downgrade di un pacchetto o dell'intera versione (caso molto delicato). Per far ciò Debian utilizza un meccanismo molto sofisticato, chiamato pinning, che permette di assegnare ai vari pacchetti una priorità per l'installazione indipendentemente dal ramo o versione di cui fanno parte (stable, testing, unstable, experimental).
Per far ciò è possibile agire su uno o entrambi i seguenti due file testuali: /etc/apt/apt.conf e /etc/apt/preferences. Di norma questi due file non sono presenti dopo un'installazione, è pertanto l'utente a doverli creare ex-novo utilizzando un qualsiasi editor di testo.
Si noti che entrambi i file devono essere definiti secondo precise regole e direttive di cui si mostreranno solo alcuni elementi base, giusto per aver un minimo di funzionalità.

  ATTENZIONE
Considerata la complessità dell'argomento, questo mini how-to ha il solo scopo all'introduzione di questa procedura, per un uso avanzato far riferimento a man apt.conf e man apt_preferences


/etc/apt/apt.conf

Delle innumerevoli direttive che è possibile dichiarare solo la seguente interessa la procedura di pinning:

APT::Default-Release

ad esempio

APT::Default-Release "stable"; 

impone ad apt di considerare la release stable come release di riferimento, attribuendogli un punteggio di 990 (si veda più avanti per una spiegazione del significato dei vari punteggi).

  Nota
  • Per quanto riguarda tutti i pacchetti della release target 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


Premesso questo in /etc/apt/apt.conf si daranno le seguenti indicazioni:

- della versione che si vuole utilizzare come default (stable)
- della dimensione della cache
- del purge dei pacchetti
- della pulizia della cache
- del fix dei pacchetti rotti (causa dipendenze non soddisfatte)
- del fix dei pacchetti non possibili da installare
- di mostrare gli upgrade dei pacchetti
- di forzare il loop dei pacchetti rotti (causa dipendenze non soddisfatte)
- di permettere l'installazione di pacchetti non autenticati (manca la chiave pubblica)

quindi il file preferences apparirà come segue

   APT::Default-Release "stable"; 

   APT::Cache-Limit 24000000;

   Apt::Get::Purge;

   APT::Clean-Installed;

   APT::Get::Fix-Broken;

   APT::Get::Fix-Missing;

   APT::Get::Show-Upgraded "true";

   APT::Force-LoopBreak=true;

   APT::Get::AllowUnauthenticated 1;
  Nota
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)

.

/etc/apt/preferences

Prima di vedere la sintassi per strutturare il file cerchiamo di capire il valore che la policy Debian assegna ad un singolo pacchetto o alla release (stable o testing) in generale:

Valore del PIN:
- superiore a 1000 ha l'assoluta priorità nell'installazione può implicare il downgrade
- da 991 a 1000 il pacchetto verrà installato anche se non fa parte della release (specificata in apt.conf), a meno che la versione installata sia più recente
- da 551 a 990 il pacchetto verrà installato a meno che ci sia disponibile una versione che fa parte della release (specificata in apt.conf) o che la versione installata sia più recente
- da 101 a 550 il pacchetto verrà installato a meno che ci sia disponibile una versione appartenente a qualsiasi release o che la versione installata sia più recente
- da 0 a 100 il pacchetto viene installato solo se non è installata nessuna versione del pacchetto
- minore di 0 previene l'installazione del pacchetto, qualsiasi sia l'origine

Avendo visto il valore del PIN possiamo adattare il nostro file /etc/apt/preferences ai nostri bisogni, bloccando o retrocedendo oppure aggiornando i vari pacchetti. Da tenere in considerazione che se usiamo una stable ed installiamo un pacchetto da testing o unstable non avremo più la garanzia che essa ci offre.

  Nota
Similmente al caso precedente è possibile creare più file di nome arbitrario in /etc/apt/apt.preferences.d/ invece di creare un unico file di nome preferences, (si veda il manuale).


Qualche esempio pratico.

Fondamentale aver creato il file /etc/apt/apt.conf (dove avremo specificato la nostra release preferita: stable o testing) e aver abilitato tutti i repository delle diverse release in /etc/apt/sources.list

deb http://ftp.it.debian.org/debian/ stable main contrib non-free

deb http://www.deb-multimedia.org stable main non-free

deb http://ftp.it.debian.org/debian/ stable-backports main contrib non-free

deb http://security.debian.org/ stable/updates main contrib non-free

deb http://ftp.it.debian.org/debian/ stable-updates main contrib non-free

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

deb http://www.deb-multimedia.org stable main non-free

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

deb http://www.deb-multimedia.org unstable main non-free


Ovviamente chi usa Testing può omettere i repository della Stable.

Ora possiamo vedere la policy Debian riguardo alle release:

apt-cache policy

ci restituirà il PIN delle release, giusto per farci un'idea.
Lo stesso per vedere la policy di un singolo pacchetto es:

apt-cache policy nano

STABLE

Prendiamo in considerazione di lavorare con una Stable e il file preferences nel seguente modo

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

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

Cerchiamo di capire il significato delle tre righe:

Package: * vuol dire tutti i pacchetti
Pin: release a=stable tutti i pacchetti della Suite (a) stable
Pin-Priority: 900 verranno installati solo pacchetti più aggiornati della stessa release (se ce ne sono)

mentre

Package: * vuol dire tutti i pacchetti
Pin: release o=Debian pacchetti di Origin (o) Debian
Pin-Priority: -10 nessuna priorità

In questo caso verranno installati solo pacchetti più aggiornati della stessa release (se ce ne sono) e nessun altro pacchetto di release diverse verrà installato.
Se si vuole installare un pacchetto proveniente dalla release Testing si possono usare due comandi:

apt-get install nome_pacchetto/testing

(installerà il pacchetto con le dipendenze della stable)

apt-get install -t testing nome_pacchetto

(installerà il pacchetto con le dipendenze della release testing. Il pacchetto non verrà più aggiornato fino a quando non ridaremo lo stesso comando)

  ATTENZIONE
Considerata la stabilità della release Stable, usare pacchetti di altre release potrebbe comprometterne la stabilità. Per avere una perfetta integrazione con Stable meglio usare il pinning con i pacchetti provenienti dai backports


Se, ad esempio, volessimo installare la versione più recente di libreoffice dai backports:

apt-get -t stable-backports install libreoffice

per evitare che nei prossimi upgrades il pacchetto venga retrocesso alla versione della Stable nel file preferences aggiungere:

Package: libreoffice
Pin: release a=stable-backports
Pin-Priority: 999

In questo modo rimarrà installata la versione del Backports.

Come detto precedentemente in questa maniera possiamo fare il downgrade sia di un pacchetto o dell'intera release, basta agire sul file preferences indicando il pacchetto o la release modificando il Pin-Priority.
Vediamo qualche esmpio concreto.

ES. n° 1 voglio il pacchetto-1.0.1 indipendentemente dalla release che utilizzo

Package: pacchetto
Pin: version 1.0.1
Pin-Priority: 1001

in questo modo pacchetto versione 1.0.1 non verrà mai scalzato né da una versione più recente né da una più vecchia (in caso di downgrade).

ES. n° 2 fare il downgrade di una release (questo passaggio è molto delicato, usatelo con cautela):

Package: *
Pin: release a=stable
Pin-Priority: 1001

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

in questo modo basta

aptitude update
aptitude safe-upgrade
aptitude full-upgrade

similmente con apt:

apt-get update
apt-get upgrade
apt-get dist-upgrade

TESTING

Se si sta utilizzando Testing e si ha l'esigenza di installare un pacchetto da Unstable o Experimental (usare con molta cautela), come visto sopra creiamo i due files /etc/apt/apt.conf e /etc/apt/preferences come segue:

/etc/apt/apt.conf

   APT::Default-Release "testing"; 

   APT::Cache-Limit 24000000;

   Apt::Get::Purge;

   APT::Clean-Installed;

   APT::Get::Fix-Broken;

   APT::Get::Fix-Missing;

   APT::Get::Show-Upgraded "true";

   APT::Force-LoopBreak=true;

   APT::Get::AllowUnauthenticated 1;


/etc/apt/preferences

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

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

Package: *
Pin: release a=experimental
Pin-Priority: 50

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

Questo farà in modo che apt installi di default i pacchetti provenienti dalla release Testing.
Se si vogliono installare pacchetti provenienti da Unstable o Experimental:

apt-get install nome_pacchetto/unstable

questo installerà il pacchetto con le dipendenze della testing

apt-get install -t unstable nome_pacchetto

questo installerà il pacchetto con le dipendenze della release unstable

Per quanto riguarda il mantenimento o il downgrade di un pacchetto specifico operare come indicato sopra nella sezione STABLE.