Discussione:Repository & pinning

Specificare APT::Default-Release mi pare renda inutile in buona parte la definizione di un file preferences, rimando a questo thread.

Le seguenti voci del file apt.conf mi sembrano scorrette

Apt::Get::Purge;
APT::Clean-Installed;
APT::Get::Fix-Broken;
APT::Get::Fix-Missing;

Non dovrebbero apparire così?

Apt::Get::Purge "true";
APT::Clean-Installed "true";
APT::Get::Fix-Broken "true";
APT::Get::Fix-Missing "true";

Tra l'altro da manuale l'utilizzo della seguente opzione è fortemente sconsigliato:

APT::Force-LoopBreak=true;

Anche utilizzare simultaneamente APT::Get::Fix-Broken; e APT::Get::Fix-Missing viene indicato come possibile fonte di rischio, anche se non grave come nel caso precedente.

Mi pare che questa guida e questa si sovrappongano in buona parte, non sarebbe il caso di unificarle?

--Wtf 23:22, 18 lug 2013 (CEST)

Riorganizzazione

Le parti generali relative ai repository sono state spostate e integrate in I repository ed il loro utilizzo

--Wtf 15:53, 20 dic 2013 (CET)

5.2 Stable con backports obbligati

Mi permetto un appunto, nella spiegazione vengono presi come esempio libreoffice e iceweasel. Viene riportato un sources.list con i backport per così dire "ufficiali" di whezzy ma non di debain mozilla.

Come presentato, a mio modo di vedere, potrebbe confondere (generalmente le guide vengono lette da chi ha meno esperienza e conoscenza), dando per scontato che iceweasel sia presente nei backport di wheezy. In realtà i suoi backport sono di terze parti ossia mozilla debian, anche se nel file preferences il Pin: release riporta la medesima voce.

Selky 15:36, 24 giu 2014 (CEST)

Hai ragione. :) Rimuovo il riferimento a iceweasel e lascio solo quello su libreoffice. HAL 9000 18:48, 24 giu 2014 (CEST)

Esempio "Stable prelevando un pacchetto da testing "

Mi pare ci sia un "errore" teorico (senza però alcuna ricaduta nella pratica) nell'esempio in oggetto, ovvero mi riferisco all'indicazione di usare l'opzione -t di apt-get per installare il pacchetto d'esempio.

Mi risulta che le priorità assegnate a pacchetti specifici nel file preferences abbiano sempre la priorità sull'indicazione di una target relase, quindi il comando da dare dovrebbe essere un semplicissimo apt-get install nome pacchetto.

Wtf 21:09, 19 mar 2015 (CET)

Non ricordo a che stavo pensando ma ipotizzo che specificare la release di default serva a installare il pacchetto di testing e anche le dipendenze, mentre per un pacchetto senza dipendenze i due metodi sono equivalenti. Ipotizzo :)
Altrimenti bisognerebbe indicare una configurazione di pinning che, automaticamente, installa il pacchetto e tutte le sue dipendenze. Ma esiste? S3v 09:51, 21 mar 2015 (CET)

Io credo che le dipendenze se le risolva autonomamente aptitude come al solito. Se ci sono conflitti non esiste configurazione che tenga. Wtf 21:20, 5 mag 2015 (CEST)

Proposte cambiamento

Unisco i miei tre messaggi precedenti, perché sennò non si capisce niente. :)

1- Partendo dall'esempio "Stable prelevando un pacchetto da testing" non mi era chiara l'utilità di avere un pacchetto in preferences, in presenza di dipendenze da prelevare dallo stesso repository ma per cui non è previsto il pinning, a meno che serva solo per ricordarsi del pinning o per prevenire l'installazione automatica di altre versioni. Esistono altri effetti per via del pinning?

2- dopo una decina di giorni dal primo messaggio

• Ho diviso l'esempio della stable con testing, presentando tre metodi per ottenere quel risultato, con leggere differenze, non so se sono da tenere tutti quanti, forse si può rimuovere il primo? (la dimensione della pagina è prossima ai 32 kB)
• Ho ridotto un po' di ridondanza con i repository, mettendo invece dei link e lasciandoli solo negli ultimi esempi, che ne hanno di non ufficiali.
• Ho tolto le opzioni Purge e Purge-Unused, non necessarie per il pinning e la seconda segnalata come potenzialmente pericolosa. E un Fix-Missing che era rimasto dalle revisioni precedenti.
• Ho rimosso la parte sulla retrocessione dell'intero sistema, lasciandola solo descrittiva in uno warning.
• Ho tagliato una configurazione di apt.conf, non richiesta per il pinning nel caso di stable e backports.

3- Nuovo e ultimo messaggio con delle domande:

È ancora importante il repository di multimedia? Io sono anni che non lo utilizzo, e credo che per usi normali (riproduzione video) sia sostanzialmente inutile. Sbaglio?

E delle proposte di cambiamento:

• rimuovere i repository di multimedia dall'ultimo esempio (è già trattato nel penultimo, e lo lascerei lì), riservando questa sezione a testing/unstable/experimental, visto che sono quelle ufficiali e questo esempio non è trattato;
• trattare anche il caso sid/experimental (basta solo per specificare che non serve pinning e che non ci sono aggiornamenti automatici per motivi di sicurezza);
• chiarire i casi in cui il pinning *NON* è necessario, avevo già scritto una sezione, ma è da estendere;
• eliminare tutti i repository da questa pagina, rimandando alle rispettive guide; (è parzialmente già fatto per quelli ufficiali nel resto della pagina);
• rimuovere le configurazioni di apt.conf, dove non necessarie. Ridurre al minimo le modifiche (per esempio perché impostare autoremove o altre opzioni, se non hanno niente a che vedere con il pinning?)
• usare ovunque /etc/apt/preferences, o sennò un file personalizzato ovunque, dopo aver specificato che si può configurare in entrambi i modi, per mantenere la consistenza della documentazione.

Aspetterò un paio di settimane prima di apportare altre modifiche, in assenza di risposte procederò con questi punti, così che per l'uscita di Jessie sia tutto a posto.

Fatemi sapere, ciao! :)

HAL 9000 17:54, 9 apr 2015 (CEST)

Parto dal punto 1 e mi fermo per non ingarbugliare tutto. A quale paragrafo ti riferisci con "Stable prelevando un pacchetto da testing"? S3v 19:16, 5 mag 2015 (CEST)

Ora è in "Stable con testing". I tre punti sono relativi a tre messaggi diversi, il primo scritto prima delle modifiche successive al punto 2 (ma c'è un riferimento in questa discussione) e di quelle proposte (ma non ancora realizzate) al punto 3. Per queste ultime proposte (tranne alcune già trattate e scartate) ho già aggiornato la discussione sul forum, e non ho ricevuto obiezioni. HAL 9000 19:26, 5 mag 2015 (CEST)

Ok :) Anche il punto 2 mi trova d'accordo con i cambiamenti fatti. Passo al 3.
- I repository multimedia sono necessari agli sviluppatori per contemplare il caso in cui un utente abbia prelevato software da lì. Quindi servono a scopo di test e li lascerei.
- Su sid hai già modificato mentre su experimental non serve il pinning (forse non è nemmeno possibile farlo)
- Una sezione separata è una buona idea. Bisogna vedere se si può eseguire il pinning anche sui repository di sicurezza e gli updates
- A parer mio andrebbero rimosse tutte le configurazioni di "apt-conf" e d'accordo nel togliere tutto ciò che non ha a che vedere con il pinning.
- Per me è uguale e concordo con l'uniformità di indicazione. Visto che gli sviluppatori hanno previsto le directory *.d/ un po' per tutto, direi di usarle ;)
S3v 19:52, 5 mag 2015 (CEST)

Io gli apt.conf li lascerei per gli esempi. La logica degli esempi è proprio quella di fornire una configurazione pienamente funzionante. Se poi invece del file apt.conf in /etc/apt/ preferite specificare /etc/apt/conf.d/ per me è del tutto equivalente

Il repository deb-multimedia server ancora, anche se molto meno che in passato. Per esempio il pacchetto monkeys-audio c'è solo nel repository deb-multimedia

Wtf 21:27, 5 mag 2015 (CEST)

Creando un file in /etc/apt/conf.d/ con la sola configurazione necessaria per il pinning, senza tutte le altre opzioni (Autoremove e quant'altro) la configurazione sarebbe completa, ma senza modificare il comportamento di default di APT e poi per ripristinare tutto basterebbe cancellare il file del pinning con la Default-Release.

Per multimedia allora lo terrei, ma se possibile in un unico esempio, anziché in due.

Altra cosa: ti va bene rimuovere tutti i repository, per non doverli aggiornare a ogni passaggio di versione? (non esiste stable-backports, ma solo jessie-backports per esempio). HAL 9000 21:51, 5 mag 2015 (CEST)

Mi sta bene, ma manterrei anche i sources.list sempre per il motivo di avere degli esempi completi. Se volete eliminare l'ultimo esempio "Mix di varie release" fate pure, io l'avevo mantenuto solo per scrupolo, visto che non l'avevo scritto io. Wtf 21:54, 5 mag 2015 (CEST)

Va bene, direi allora di aggiungere nuovamente i sources.list per tutti gli esempi, in fondo la comodità di chi ci legge viene prima della nostra. :)

E concordo con il rimuovere l'ultimo esempio. Prima di apportare le modifiche però, aggiornerei anche la discussione del forum e aspetterei un po', nel caso volesse intervenire qualcuno, anche per riflettere i cambiamenti emersi in quest'altra. HAL 9000 22:10, 5 mag 2015 (CEST)

Qual'è la discussione sul forum (doh!)? Wtf 00:02, 6 mag 2015 (CEST)

Mio errore, avevo solo continuato una discussione precedente. Ho rimosso da lì intanto i punti cambiati nel corso di questa discussione. :) HAL 9000 08:52, 6 mag 2015 (CEST)

A proposito del primo esempio "Stable con testing", non sono sicuro che dichiarare a -1 il pinning di tutti i pacchetti di testing serva a qualcosa. Io mi aspetterei che tale dichiarazione venga semplicemente ignorata da APT nel momento in cui si calcola dipendenze per il pacchetto specificato di testing. Tu hai verificato il contrario? Wtf 21:59, 5 mag 2015 (CEST)

Ok, stupido io. La dichiarazione l'hai messa per evitare che quando uno lancia upgrade tutto il sistema passi a testing. Wtf 22:02, 5 mag 2015 (CEST)

Espliciterei però meglio la seconda parte del warning. Se il pacchetto specificato è uno solo il rischio che paventi è davvero remoto a mio parere. Diversamente sarebbe se uno installasse molti pacchetti da testing. Wtf 22:04, 5 mag 2015 (CEST)

Ho fatto una prova veloce con amule (che non si trova in Jessie, ma solo in Sid). Confermo che se le dipendenze sono bloccate con pinning a -1, allora lo è anche il pacchetto, nonostante un pinning di 990. A ogni modo aptitude ha un meccanismo di risoluzione dei conflitti automatici, quindi può proporre come soluzione quello di ignorare il pinning (a me l'ha fatto come seconda soluzione dopo quella di non installare il pacchetto, proponendomi di installare le dipendenze da Sid). Lo stesso non avviene invece con apt e apt-get, che si limitano a uscire. HAL 9000 22:10, 5 mag 2015 (CEST)

Questo mi è sembrato strano perché quando scrissi quella configurazione aveva funzionato tutto correttamente. Ho anch'io fatto una prova con "amule" e (simulazione "-s") il pacchetto viene normalmente installato con alcune dipendenze prese da sid mentre altre sono prese da stretch (su cui mi trovo). Quindi non ho interpretato bene ciò che hai scritto: a te il pacchetto non si installa? S3v 00:35, 6 mag 2015 (CEST) (EDIT) Dimenticavo che quella configurazione valeva per "un solo pacchetto" :D Con le dipendenze confermo che il "-1" va tolto.

Dipendenze

Serve una spiegazione di come si comportano le dipendenze di un pacchetto prelevato col pinning. Da dove vengono prese? E soprattutto, sono soggette a pinning a loro volta (presumo di no)?
Questo perché il pinning di un pacchetto singolo non costituisce un problema ma la gestione delle sue dipendenze, soprattutto se molte, è davvero criptica. S3v 19:21, 5 mag 2015 (CEST)

Le dipendenze non sono affette dal pinning. Se un pacchetto ha delle dipendenze, questo viene aggiornato soltanto se la priorità di tutte le sue dipendenze lo permette. L'unico modo è utilizzare * (se iniziano con lo stesso prefisso), o elencarne una a una, ma non c'è garanzia che non cambino, soprattutto per backports e testing/unstable/experimental. HAL 9000 19:26, 5 mag 2015 (CEST)

Lo sospettavo. Direi di specificare abbastanza chiaramente che le dipendenze non vengono gestite automaticamente da APT in caso di pinning (o almeno si ha una gestione semi-automatica) e che la loro risoluzione presuppone un coinvolgimento non passivo dell'utente. S3v 19:54, 5 mag 2015 (CEST)

Non avevo capito inizialmente le vostre osservazioni. Concordo anche io che il pinning non si estende alle dipendenze e altresì concordo nell'affermare che sia meglio scrivere questa cosa esplicitamente (io la davo per scontata ad esempio). Io però specificherei anche che le dipendenze vengono risolte automaticamente e che quindi non è necessario esplicitarle autonomamente. L'unico caso in cui si possono avere problemi è quello in cui ci siano dei conflitti con le dipendenze, ad esempio due pacchetti dipendono da uno stesso medesimo pacchetto, ma di differente versione. In tal caso però anche specificare manualmente tutte le dipendenze non risolve nulla. Wtf 21:32, 5 mag 2015 (CEST)

Giusta osservazione, sennò si rischia di creare un altro fraintendimento (sulla necessità di specificare le dipendenze). :) 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 [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, Clean-Installed). 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 apt upgrade, che è consigliabile a partire da Jessie, oppure apt-get dist-upgrade);
• 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).

HAL 9000 13:36, 11 mag 2015 (CEST)