Repository & pinning: differenze tra le versioni

m
Riga 162: Riga 162:
= Esempi =
= Esempi =


{{Box|Nota|Per il significato dei vari parametri dichiarati in <code>apt.conf</code> si vedano le guide dedicate ad [[apt-get]], [[aptitude]], ecc.}}
{{Box|Nota|Per il significato dei vari parametri dichiarati in <code>apt.conf</code> si vedano le guide dedicate ad [[apt-get]], [[aptitude]], ecc. Si ricordi inoltre che non sempre la definizione di tale file è necessaria ai fini del pinning.}}


== Release pura ==
== Release pura ==
Riga 297: Riga 297:
</pre>
</pre>


=== Conseguenze ===
=== Osservazioni ===


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.
# 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 <code>apt-get install vattelapesca -t unstable</code> 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 <code>apt-get upgrade</code> o <code>apt-get dist-upgrade</code> 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 <code>apt-get install vattelapesca -t unstable</code> (o aspettare pazientemente che la versione di testing superi quella installata).
# Digitando <code>apt-get install vattelapesca -t unstable</code> 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 <code>apt-get upgrade</code> o <code>apt-get dist-upgrade</code> 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 <code>apt-get install vattelapesca -t unstable</code> (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.
# 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 (a meno ovviamente di non aggiungere opportuni record in <code>preferences</code>).


== Testing con deb-multimedia ==
== Testing con deb-multimedia ==
Riga 361: Riga 361:
=== Osservazioni ===
=== 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 <code>apt.conf</code> una distribuzione obiettivo e definendo in <code>preferences</code> 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 <code>apt.conf</code> risultando perfino inutile definire un file <code>preferences</code>, visto che come già detto di norma i candidati di deb-multimedia hanno numero di versione maggiore di queli del repository principale.
# 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 <code>apt.conf</code> una distribuzione obiettivo e definendo in <code>preferences</code> 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 <code>apt.conf</code> risultando perfino inutile definire un file <code>preferences</code>, visto che come già detto di norma i candidati di deb-multimedia hanno numero di versione maggiore di queli del repository principale.


* L'utilizzo dell'opzione '''-t''' in questo caso è inutile, visto che si lavora per ipotesi con una sola distribuzione.
# 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 (a meno ovviamente di non aggiungere opportuni record in <code>preferences</code>).
# L'installazione di tutti i pacchetti provenienti da distribuzioni differenti da testing è completamente impedita, anche nel caso si aggiungessero repository relativi ad altre distribuzioni (a meno ovviamente di non aggiungere opportuni record in <code>preferences</code>).


* La definizione di un file <code>apt.conf</code> in questo esempio non è necessaria ai fini del pinning.
# La definizione di un file <code>apt.conf</code> in questo esempio non è necessaria ai fini del pinning.


== Mix di varie release ==
== Mix di varie release ==
3 155

contributi