I repository ed il loro utilizzo: differenze tra le versioni

I repository ed il loro utilizzo (visualizza wikitesto)

Versione delle 18:12, 19 lug 2013

2 462 byte aggiunti , 19 lug 2013

→‎Pinning

Wtf

3 155

contributi

@@ Riga 120: / Riga 120: @@
 <br/><br/>
 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>
+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.
+=== 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 al "rilascio obiettivo", dove con quest'ultimo termine si deve intendere "Default Release", "Target Release".
+* '''priorità 990''' alle versioni che non sono installate e non appartengono al "rilascio obiettivo", dove con quest'ultimo termine si deve intendere "Default Release", "Target Release".
+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);
+* il suddetto pacchetto è presente in tre repository, repoA, repoB, repoC tutti 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);
+* la versione di "vattelapesca" in repoA è la 1.4, in repoB la 2.0 e in in repoC la 1.3;
+* 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 è stato dichiarato il parametro ''Default Release'' in un eventuale file <code>apt.conf</code>.
+Nel momento in cui l'utente esegue il comando <code>apt-get install vattelapesca</code> saranno assegnati i seguenti punteggi:
+* 100 a "vattelapesca" presente in repoC;
+* 500 a "vattelapesca" presente in repoB;
+* 500 a "vattelapesca" presente in repoA;
+Il pacchetto proveniente da C viene immediatamente scartato; a questo punto APT effettuerà la sua scelta 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 esplode poi 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.
+DA CONTINUARE
 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.