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)

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)