I repository ed il loro utilizzo: differenze tra le versioni

Vai alla navigazione Vai alla ricerca

I repository ed il loro utilizzo (visualizza wikitesto)

Versione delle 09:34, 20 lug 2013

1 756 byte aggiunti ,  20 lug 2013
→‎Pinning
Riga 111: Riga 111:
=== Introduzione ===
=== Introduzione ===


Come molti sapranno, esistono tre versioni di Debian (chiamate anche release):
Come molti sapranno, esistono tre distribuzioni di Debian (chiamate anche release):
# Debian stable, attualmente ''Wheezy'';
# Debian stable, attualmente ''Wheezy'';
# Debian testing, attualmente ''Jessie'';
# Debian testing, attualmente ''Jessie'';
# Debian unstable, attualmente (e sempre,  un nome fisso) ''Sid''.
# 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.
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.
<br/>
 
Vi invito ad un approfondimento dell'argomento (approfondimento che personalmente considero molto interessante), sia sulle precise differenze tra le versioni, sia sui meccanismi che portano al passaggio da una versione a un'altra².
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.
<br/><br/>
{{Warningbox|Installare pacchetti provenienti da distribuzioni e/o fonti differenti è sempre e comunque fonte di possibili rischi, anche se piccoli}}
Ora, 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 versione di Debian diversa da quella in uso o anche solo appartenente alla stessa distribuzione, ma proveniente da un altro repository. Tutto ciò eliminando il rischio di creare problemi nel sistema e nel gestore dei pacchetti poiché non è detto che l'attribuzione di priorità automatica dia il risultato voluto e/o migliore.<br>
 
Il pinning permette anche di scegliere se installare solo un pacchetto da un'altra versione o anche le sue relative dipendenze (alternativamente, verranno utilizzate le dipendenze della versione in uso, se disponibili).<br/>
Prima di procedere nella descrizione operativa del pinning è '''fondamentale''' capire come gestisce la priorità dei pacchetti APT e sapere che:
Prima di procedere nella descrizione operativa del pinning è '''fondamentale''' capire come gestisce la priorità dei pacchetti APT.
* col termine distribuzione si intendono stable, testing e unstable. Ciascuna distribuzione ha un suo singolo repository (due se si conteggia anche l'eventuale repository dedicato agli aggiornamenti di sicurezza).
* 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.
* Il pinning nasce come strumento per regolare la priorità in base al numero di versione dei pacchetti, e non alla loro fonte. È tuttavia possibile gestire anche questo secondo caso, almeno in parte, prestando attenzione.


=== Priorità come punteggio ===
=== Priorità come punteggio ===
Riga 131: Riga 133:


Piccolo esempio teorico. Si supponga quanto segue:
Piccolo esempio teorico. Si supponga quanto segue:
* si desidera installare il pacchetto "vattelapesca" appartenente al proprio rilascio obiettivo, cioè quello che si è installato (si supponga testing);
* 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 repository, repoA, repoB, repoC tutti correttamente specificante nel file <code>source.list</code>;
* il suddetto pacchetto è presente in tre fonti, repoA, repoB, repoC tutte correttamente specificante nel file <code>source.list</code>;
* tutti i pacchetti presenti in repoA appartengono al rilascio obiettivo (ad esempio testing), in repoB e repoC sono contenuti pacchetti appartenenti ad un'altra distribuzione (ad esempio unstable e stable rispettivamente);
* 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;
* 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";
* nel sistema è installata la versione 1.3 di "vattelapesca";
* non esiste un file <code>preferences</code> o comunque non è stata specificata una priorità per nessuno dei tre rilasci considerati;
* non esiste un file <code>preferences</code> o comunque non è stata specificata una priorità per nessuno dei tre rilasci considerati;
* non è stato dichiarato il parametro ''Default Release'' in un eventuale file <code>apt.conf</code>.
* non è stato dichiarato il parametro ''Default Release'' in un eventuale file <code>apt.conf</code>, ovvero non è stata esplicitamente definita una distribuzione obiettivo.


Nel momento in cui l'utente esegue il comando <code>apt-get install vattelapesca</code> saranno assegnati i seguenti punteggi:
Nel momento in cui l'utente esegue il comando <code>apt-get install vattelapesca</code> saranno assegnati i seguenti punteggi:
Riga 146: Riga 148:
Il problema evidentemente non può che esplodere quando si esegue il comando <code>apt-get upgrade</code> (o peggio <code>apt-get dist-upgrade</code>), cioè quando si tenta di aggiornare tutti i pacchetti di sistema.
Il problema evidentemente non può che esplodere quando si esegue il comando <code>apt-get upgrade</code> (o peggio <code>apt-get dist-upgrade</code>), 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.
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 <code>sources.list</code>.


Affinché questo sia possibile, è necessario innanzitutto istruire apt secondo i nostri desideri. I file in questione sono due e precisamente <code>/etc/apt/apt.conf</code> e <code>/etc/apt/preferences</code>, che ora andremo ad analizzare. In un'installazione di default questi due file non sono normalmente presenti (vengono utilizzate delle impostazioni di default), quindi dovremmo procedere col crearli manualmente con i privilegi di root.
* 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.
* 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 <code>apt.conf</code>).
* 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.


=== Il file /etc/apt/apt.conf ===
=== Il file /etc/apt/apt.conf ===
Wtf
3 155

contributi

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

Menu di navigazione