Salve, alla fine della guida (peraltro chiarissima) viene indicato di creare un file dove inserire le preferenze per l'aggiornamento dei pacchetti backports in /etc/apt/preferences.d/; il file deve avere un nome particolare, immagino... potreste indicarlo, o chiarire questo aspetto? Grazie mille e a presto :-) --Contemoon 18:47, 14 mar 2013 (CET) Edit: noto anche che [[1]] viene invece indicato /etc/apt/preferences come il file dove inserire le preferenze; si tratta di una variazione dovuta al camio di versione? Scusate le domande che possono apparire sciocche. Grazie ancora --Contemoon 18:55, 14 mar 2013 (CET)
Si possono usare indifferentemente il file preferences o la cartella preferences.d e i file all'interno della cartella posso avere un nome qualsiasi (anche se credo che in caso di conflitti di impostazioni tra file diversi dentro preferences.d vengano prese in considerazione quelle contenute nel file che in ordine alfabetico viene prima). BubuXP 15:00, 15 mar 2013 (CET)
- Aggiungo solo una precisazione: i file d'impostazione personali dovrebbero andare in
preferences.d/per evitare che, in caso di aggiornamenti del filepreferences, APT tenti di sovrascriverlo. In ogni modo verrà comunque chiesto cosa fare (sovrascivere, leggere i cambiamenti, etc.). I file inpreferences.d/sono nient'altro che prosecuzioni del filepreferences: è come se si avesse un unico file in cui le impostazioni seguenti sovrascrivono uguali impostazioni precedenti. Lo stesso comportamento si presenta per tutti i file che possono avere impostazioni personali (sudoers.d/,grub.d/,init.d/e così via). S3v 18:25, 15 mar 2013 (CET)
Pin-Priority non più necessario per gli aggiornamenti automatici
Al meglio della mia comprensione (è partito tutto da qui: http://forum.debianizzati.org/viewtopic.php?f=42&t=49387&sid=29931ffb1daf29c3a936666b7a3c1c54) e leggendo anche su debian.org (https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports) riguardo i backports, la situazione è cambiata rispetto al passato.
Seguendo la guida presente sul wiki tutto funziona comunque, e immagino sia per questo che nessuno ha notato il cambiamento, ma ora il file Release dei backports ufficiali riporta:
... NotAutomatic: yes ButAutomaticUpgrades: yes ...
In pratica il valore di default di Pin-Priority per i backports è 100, anziché 1 come per gli experimental, 990 per l'eventuale default release (se specificata) e 500 per tutti gli altri repository.
Considerando una situazione con solo i repository della stable (normali + security), eventualmente gli updates (ex-volatile) e i backports, senza impostare nulla in /etc/apt/preferences (e directory preferences.d) e senza impostare la default release in /etc/apt/apt.conf (o in un file nella directory apt.conf.d), la situazione sarebbe la seguente:
Pin-Priority stable: 500 Pin-Priority updates: 500 Pin-Priority backports: 100
Quindi i pacchetti dai backports non verrebbero installati automaticamente, perché verrebbero sempre scelti quelli stable o gli updates, ma una volta installati manualmente verrebbero aggiornati in automatico, in quanto sarebbero quelli più recenti rispetto a quelli presenti in stable (+ security).
Il man di apt_preferences (P è la Pin-Priority) è un po' ambiguo:
100 <= P < 500
causes a version to be installed unless there is a version available belonging to some other distribution or the installed version is more recent
ma la "versione disponibile" dell'altra distribuzione in realtà è scelta solo se i backports non sono stati installati manualmente e non c'è quindi da effettuare un downgrade (per cui servirebbe un Pin-Priority maggiore o uguale a 1000):
P >= 1000
causes a version to be installed even if this constitutes a downgrade of the package
990 <= P < 1000
causes a version to be installed even if it does not come from the target release, unless the installed version is more recent
500 <= P < 990
causes a version to be installed unless there is a version available belonging to the target release or the installed version is more recent
Volevo chiedere conferma, perché tutta la questione è abbastanza ingarbugliata. :) HAL 9000
- Credo ci sia una differenza tra installazione dai backports di un programma non precedentemente installato dalla release di default (ad es. un kernel recente per Wheezy - 3.14 non presente negli archivi di Wheezy) e l'aggiornamento presente nei backports di un programma già installato dagli archivi della release di default.
Nel primo caso il pinning non è necessario mentre nel secondo sì (ovviamente solo se si vogliono ancora aggiornamenti automatici dai backports, se disponibili in futuro per quel programma).
Ma chiedo anche io conferme. S3v 12:12, 15 giu 2014 (CEST)
- Grazie della risposta. :)
Parlando della situazione di default, non dovrebbe esserci una Default-Release in apt.conf (o in un file in apt.conf.d). E la stable avrebbe quindi priorità 500 (ma non dovrebbe cambiare, visto che anche a 990 sarebbe inferiore a 1000). I backports ufficiali invece, senza pinning, avrebbero una priorità 100 per via del loro file Release.
Mentre concordo che un pacchetto non verrebbe aggiornato né installato automaticamente dai backports, ma ci vorrebbe un comando manuale (apt-get/aptitude -t wheezy-backports install ...), una volta installata la versione presente nei backports si dovrebbe aggiornare da lì in automatico, senza bisogno di cambiare il pinning.
La situazione dovrebbe essere questa, quando arriverà una nuova versione tramite i backports:
* Pin-Priority di stable: 500, è il valore più alto, ma è inferiore a 1000 e quindi non comporterebbe il downgrade; di fatto quindi la loro esistenza è ignorata, visto che è già stata installata una versione più recente;
* Pin-Priority del pacchetto installato localmente: 100;
* Pin-Priority dei backports, che contengono la nuova versione aggiornata: 100.
E quindi effettuerebbe l'aggiornamento in automatico, perché la Pin-Priority è almeno pari a quella locale e la nuova versione dei backports è più recente. Non saprei come replicare il comportamento, e mi baso solo sulla lettura di Debian reference, ma posso affermare che per stable (priorità 990) con pacchetti da Sid (priorità 500), i pacchetti da Sid si sono sempre aggiornati da soli.HAL 9000 13:48, 16 giu 2014 (CEST)
- Grazie della risposta. :)
- Alla luce anche di questo resoconto e in assenza di altre obiezioni provvedo all'aggiornamento della guida. HAL 9000 10:21, 24 giu 2014 (CEST)
backports-sloppy e altro
Bisogna aggiungere:
- jessie-backports per i backports da Stretch a Jessie;
- wheezy-backports-sloppy per i backports da jessie-backports a Wheezy, specificando che permette il passaggio di versione (a Jessie + Jessie backports).
E lasciare wheezy-backports per i backports da Jessie a Wheezy, specificando che permette il passaggio di versione.
Manca inoltre la sezione su LTS, al momento disponibile per Squeeze, e che è già stata confermata per Jessie e Stretch. E va inserita da qualche parte nel template.
Per repository ufficiali, speciali, e questa pagina inoltre avevo proposto (qui) di ripartire da capo con il numero di revisori a ogni modifica, visto che l'elemento principale da verificare è proprio la correttezza dei repository e dovrebbe essere facile ottenere almeno 5 membri del forum a conferma, in modo che queste guide siano sempre "debianizzate". :)
HAL 9000 21:04, 7 mag 2015 (CEST)
- Gli sloppy non permettono il passaggio da Wheezy a Stretch? http://backports.debian.org/Instructions/#index4h2
Leggo "per il passaggio dalla precedente stable (Wheezy) alla prossima stable ("next stable" - quindi Stretch),
Sulle revisioni, io ho sempre messo la revisione e poi non mi sono mai preoccupato di aggiornarne la data. Per me la guida resta revisionata indipendentemente dalla data che c'è scritta. inoltre la guida sui repository resta praticamente invariata nel tempo, per cui lascerei i revisionanti senza doverli recuperare ad ogni rilascio ;) S3v 22:15, 7 mag 2015 (CEST)
- Il passaggio di pacchetti da Stretch a Wheezy, sì. Penso comunque che i pacchetti presi da Stretch in wheezy-backports-sloppy saranno un sottoinsieme di quelli presi da Strech in jessie-backports, almeno se i squeeze-backports-sloppy sono indicativi.
- Ok per il resto. Una volta finite queste revisioni però chiederò un'opera di verifica sul forum, così che diventino debianizzate. In fondo davvero non ci vuole niente a confrontare i repository con quelli sulla pagina ufficiale. :)
- EDIT: dimenticavo, visto che i backports devono essere indicati per codename, propongo di cambiare il template versioni compatibili per metterci Wheezy e Jessie. In alternativa se si lascia "stable" va modificato il template per contemplare la "oldstable" e potenzialmente anche la "oldoldstable", ma penso diventi solo più complicato.
- HAL 9000 22:38, 7 mag 2015 (CEST)
- Mi sono fatto l'idea che si tratti di un repository che verrà "riempito" molto in là visto che Stretch è appena nata e le dipendenze tra pacchetti devono ancora consolidarsi. Attualmente c'è un solo pacchetto ma penso sia stato inserito per sbaglio: ftp://ftp.us.debian.org/debian/dists/oldstable-backports-sloppy/main/binary-amd64/
Ok per la chiamata sul forum sulle verifiche alla guida.
Ok per la modifica del template. Però devo prima controllare quali e quante guide presentano "stable" o "testing". S3v 23:32, 7 mag 2015 (CEST)
- Mi sono fatto l'idea che si tratti di un repository che verrà "riempito" molto in là visto che Stretch è appena nata e le dipendenze tra pacchetti devono ancora consolidarsi. Attualmente c'è un solo pacchetto ma penso sia stato inserito per sbaglio: ftp://ftp.us.debian.org/debian/dists/oldstable-backports-sloppy/main/binary-amd64/
- Io volevo dire di mettere {{Versioni compatibili|Wheezy|Jessie}} in questa pagina, al posto di {{Versioni compatibili|stable}}, non so se mi sono espresso male. :) HAL 9000 23:39, 7 mag 2015 (CEST)
- Ah. Avevo capito male :) Il template non l'ho modificato ma non dovrebbero più esserci guide con parametri "stable" o "testing" (erano anche pochissime). Sulla LTS, la scrivo io. Il tempo di virtualizzare una wheezy. S3v 00:00, 8 mag 2015 (CEST) (EDIT) ehm... una squeeze ;)
- Ok. :) "Backport da unstable a testing" comunque lo lascerei "testing", così assieme a "Installare Debian SID" saranno le uniche due guide con suite al posto dei codename. HAL 9000 11:13, 8 mag 2015 (CEST)
Utilizzo template Codename - task Revisione Wiki #61
Considerando che questa pagina è già Debianized, prima di modificarla apro questa discussione e aspetterò il prossimo fine settimana. (Esiste già una sul forum, quella relativa al task di Revisione Wiki riportato nella riga successiva.)
Come le altre del task #61 di Revisione Wiki, considerando che questa pagina è e resterà:
- compatibile per tutte le versioni;
- tra le più importanti da mantenere aggiornata;
i codename delle varie release di Debian saranno sostituiti, dove sono sempre da rimpiazzare con il codename dell'attuale oldstable/stable/testing, con l'output prodotto dal template Codename ({{Codename|oldstable}}/{{Codename|stable}}/{Codename|testing}}).
Questo nuovo template, lo ricordo, non va assolutamente utilizzato al di fuori di queste guide (principali e compatibili per tutte le versioni) o quelle di glossario. Semplificherà soltanto la procedura di aggiornamento a ogni nuovo rilascio di Debian.
HAL 9000 13:30, 3 apr 2016 (CEST)
- Aggiornamento: Fatto. HAL 9000 16:12, 8 apr 2016 (CEST)