Discussione:Repository & pinning: differenze tra le versioni

Vai alla navigazione Vai alla ricerca
Riga 127: Riga 127:


:: Giusta osservazione, sennò si rischia di creare un altro fraintendimento (sulla necessità di specificare le dipendenze). :) [[Utente:HAL 9000|HAL 9000]] 21:49, 5 mag 2015 (CEST)
:: Giusta osservazione, sennò si rischia di creare un altro fraintendimento (sulla necessità di specificare le dipendenze). :) [[Utente:HAL 9000|HAL 9000]] 21:49, 5 mag 2015 (CEST)
== Sommario di tutte le modifiche apportate ==
Lascio un link alla discussione del forum, in particolare alla parte da [[http://forum.debianizzati.org/viewtopic.php?f=25&t=48541&start=30#p193316 questo mio messaggio]] in poi, che spiega l'origine degli ultimi cambiamenti.
Sommario delle modifiche più importanti apportate, anche in precedenza:
* utilizzare apt.conf e preferences per evitare confusione, specialmente in caso di presenza di altri file di configurazione, lasciando le directory apt.conf.d e preferences.d per eventuale software di sistema;
* non usare mai apt.conf e preferences assieme, per via dei possibili conflitti tra i due (e non parliamo neanche del fatto che con l'uso dell'opzione -t si possono disabilitare in una volta sola entrambe le impostazioni, in alcuni casi specifici). Se basta Default-Release in apt.conf si usa quello, altrimenti lo si lascia vuoto e si passa a preferences;
* evitare opzioni potenzialmente pericolose in apt.conf (FixMissing, Force-LoopBreak), che possono causare perdita di dati installati e le configurazioni (Purge, Purge-Unused; in particolare per DB credo), meno sicure (AllowUnauthenticated), inutili (Cache-Limit; ora illimitato di default) e comunque non attinenti al pinning (AutomaticRemove). Apt.conf necessita, eventualmente, soltanto della riga "APT::Default-Release";
* uso di codename (jessie, stretch) al posto di suite/archive (stable, testing) per stable+testing per sources.list, apt.conf e preferences, in modo che la configurazione non cambi quando Stretch diverrà la nuova stable;
* iso di suite (testing) solo quando non si hanno repository di stable;
* i file Release di backports ed experimental sono stati aggiornati per impedire installazioni automatiche (e in caso di experimental anche aggiornamenti automatici) dei pacchetti già presenti in altri rami;
* non consigliare di conseguenza alcun pinning per i backports, per via dell'impossibilità di "garantirli", salvo intervento di aptitude (facendo particolare attenzione alle soluzioni proposte, che non mi sento però di consigliare a chi non è esperto) o assegnare la stessa priorità a tutto il repository backports, che è sconsigliato dai Debian Developer; basta in fondo utilizzare l'opzione -t e poi tutto si aggiornerà automaticamente (in particolare utilizzando <code>apt upgrade</code>, che è consigliabile a partire da Jessie, oppure <code>apt-get dist-upgrade</code>);
* consigliare pinning a una selezione di pacchetti invece di tutta una release, soltanto se poi è possibile fare a meno dell'intervento manuale (con opzione -t), altrimenti accontentarsi di definire una Pin-Priority a tutto il repository che lo renda simile ai backports (per esempio un valore qualsiasi tale che: 100 <= Pin-Priority < 500). Questo è necessario per non disabilitare gli aggiornamenti automatici;
* divisione di tutti gli esempi in due sezioni, una dove è '''sconsigliato''' il pinning e l'altra dove invece è necessario per impedire il passaggio di versione alla più recente (anche se le soluzioni miste restano sconsigliate), in modo da facilitarne la ricerca (spero).
[[Utente:HAL 9000|HAL 9000]] 13:36, 11 mag 2015 (CEST)
3 581

contributi

Menu di navigazione