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 menterrei 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)

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 solo per evitare che quando uno lancia upgrade tutto il sistema passi a testing. Wtf 22:02, 5 mag 2015 (CEST)

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)