Direi di inserire anche Experimental nella sezione dei repository speciali.

MadameZou 22:32, 22 gen 2010 (CET)

A cosa si riferisce quel riferimento nella frase "Il repository di apt-build (Rif. 7.1 Pag. [*]):" ?
http://guide.debianizzati.org/index.php/I_repository_ed_il_loro_utilizzo#Alcuni_esempi

Occhio che avendo splittato la guida ci sono alcuni anchor rotti, ne ho trovati già un paio perciò c'è da dare una controllata a qualsiasi altra guida che faccia riferimento ai repository.

Un po' ovunque il template incasina i "[modifica]" per cui ho abbassato il testo, sinceramente non mi piace granché ma non ho altre idee.
Noto però che qui http://guide.debianizzati.org/index.php/VimCS:_Basi e qui http://guide.debianizzati.org/index.php/Repository_Debianizzati.Org il problema non c'è, "[modifica]" si affianca al sommario, la differenza sta nel tipo di "Title" di livello 1 anziché 2 come nelle altre pagine.
Che si fa? Si lascia così o si cambiano i livelli dei titoli?

mah...non capisco, se "I repository speciali" è di livello uno perché "Debian proposed updates" ci si allinea senza problemi? http://guide.debianizzati.org/index.php/Repository_speciali

e invece perché qui non funziona nemmeno con un livello 1? http://guide.debianizzati.org/index.php/I_repository_ed_il_loro_utilizzo
se c'è una logica non la colgo, a questo punto non è nemmeno causa del template come credevo...

skizzhg 08:21, 09 giu 2011 (CEST)

Quel riferimento non so proprio dove voglia andare a parare, direi di toglierlo.

Per l'incasinamento globale credo sia dovuto alla presenza del template "Versioni compatibili"; il sommario dovrebbe essere messo a parte sulle pagine successive alla prima per le guide molto lunghe. Se si inseriscono contemporaneamente i template "Sommario", "Versioni compatibili" e, peggio ancora, "Debianized" si va incontro a problemi abbastanza gravi.

Non so se inserire un sommario orizzontale possa risolvere il problema; per me sarebbe la soluzione migliore poiché, sviluppandosi in verticale, il sommario influenza negativamente la lettura della guida.
Questo vale per tutte le guide che fanno uso del sommario; in verità com'è fatto ora, graficamente e concettualmente, mi piace poco.

Per i riferimenti interrotti bisognerebbe controllare adesso la versione della guida precedente e quindi tutte le guide che ad essa si linkavano.
Mancano anche i riferimenti alla categoria per le nuove guide create.

S3v 20:57, 12 giu 2011 (CEST)

Problema indice guide

Aperta discussione a questo thread qui ==> http://forum.debianizzati.org/viewtopic.php?f=25&t=43884

netselect

Credo che sia utile aggiungere un paragrafo sull'uso di netselect per la scelta del mirror più performante.

Qui qualche link trovato con una rapida ricerca:

Qualcuno ha voglia di buttar giù due righe?--Stemby 15:52, 10 set 2012 (CEST)

Ridondanza

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

LOL, non mi ricordavo nemmeno più di aver copiato io la parte del pinning...

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

Per la verità le guide da unificare sarebbero tre: Revisione Wiki, task 49 S3v 19:38, 19 lug 2013 (CEST)

Ops, sono quattro :) Ovviamente in alcune c'è solo la parte che parla del pinning, altre vi sono dedicate completamente. Giustamente, come scrivi, andrebbe creata un'unica guida che parla del pinning e, eventualmente, link o riferimenti ad essa nelle altre. Magari anche una voce "pinning" del glossario non sarebbe male.S3v 21:17, 19 lug 2013 (CEST)

Viste. Wtf 17:55, 20 lug 2013 (CEST)

contrib senza non-free

Ha senso l'uso di "main contrib" senza non-free? Mentre le dipendenze (e perfino i raccomandati, di default installati in automatico) di ogni pacchetto di main devono essere presenti in main, qual è il significato di contrib senza non-free e per quali ragioni potrebbe essere desiderabile? HAL 9000 19:19, 21 giu 2014 (CEST)

Ha senso se non vuoi installare pacchetti contrari alle DFSG. I pacchetti di contrib starebbero in main se, tra le loro dipendenze, non avessero pacchetti presenti in non-free. Un esempio è VirtualBox, completamente open se tra le proprie dipendenze non avesse ad esempio le guest-additions (a sorgente chiuso ma che è comunque un pacchetto suggerito che non pregiudica l'installazione di VB). Vado a memoria ma non mi pare di ricordare pacchetti di contrib la cui installazione sia impossibile senza abilitare l'area non-free.
Una puntualizzazione: i raccomandati vengono installati in automatico solo da apt-get, aptitude non lo fa :) S3v 19:44, 21 giu 2014 (CEST)

Ok, chiaro, grazie. :) Pensavo che, salvo per i wrapper che servono per scaricare o estrarre software proprietario, tutta l'area contrib fosse inutile senza la non-free. HAL 9000 20:51, 21 giu 2014 (CEST)

Rimozione/spostamento parti ridondanti

Per una discussione, rimando al forum: http://forum.debianizzati.org/viewtopic.php?f=25&t=49814&p=184400#p184385

HAL 9000 20:09, 29 ago 2014 (CEST)

È terminata anche la parte di uniformazione di tutti i repository. Avevo iniziato con l'aggiungere sorgenti (commentati), ma visto che ce n'erano già di non commentati li ho messi ovunque non commentati, seguendo la configurazione di default dopo una nuova installazione, spiegando come disabilitarli.
Ho annullato la mia aggiunta della doppia sezione per stable, penso creasse confusione, ed esteso un po' quella di experimental.
Ci sono dei link a sezioni di altre guide, che funzionano finché il titolo non viene cambiato (ma se lo fosse punterebbero comunque alla pagina principale della guida); non so se vanno bene, ma i titoli riguardano Sid ed experimental, che non dovrebbero cambiare.
HAL 9000 21:54, 2 set 2014 (CEST)

Proposed updates

Perché non va "http://ftp.it.debian.org stable-proposed-updates" ? L'archivio c'è ma compare questo messaggio;

W: Distribuzione in conflitto: http://ftp.it.debian.org stable-proposed-updates Release (atteso stable-proposed-updates ma ottenuto wheezy-proposed-updates)

Vuole "wheezy" al posto di "stable" :(

Non so se è un errore passato inosservato, come probabile, né se è correlato al problema che hai riscontrato, ma ho notato adesso che mentre in http://ftp.it.debian.org/debian/dists ci sono sia stable-proposed-updates sia wheezy-proposed-updates, nel file Release come suite c'è scritto proposed-updates (anziché stable-proposed-updates) e invece il codename è wheezy-proposed-updates.
Per testing invece la suite è testing-proposed-updates.
HAL 9000 10:05, 27 set 2014 (CEST)

Ho trovato questo: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714726 . Sembra che il problema riguardi anche "stable-backports". S3v 10:48, 27 set 2014 (CEST)

Dei backports lo sapevo, ma non avevo pensato a un bug, perché è così anche per testing-backports. A questo punto, quando e se sarà corretto, ci sarà da ricontrollare le pagine su backports, repository, suite, codename, ecc... presenti nella wiki. HAL 9000 11:10, 27 set 2014 (CEST)

Ok.
Capisco "jessie-proposed-updates" in prospettiva futura ma il senso di "testing-proposed-updates"? :D S3v 11:36, 27 set 2014 (CEST)
... e c'è anche "testing-updates" ... S3v 11:38, 27 set 2014 (CEST)
"testing-updates" in effetti serve. Errore mio. "testing-proposed-updates" invece non so quale sia la sua utilità. S3v 11:42, 27 set 2014 (CEST)

Non ne ho idea, e ignoro anche a cosa serva testing-updates. Pensavo che testing ricevesse aggiornamenti soltanto da Sid e dal repository di sicurezza. Forse è solo per completezza. HAL 9000 13:39, 27 set 2014 (CEST)

Ho fatto confusione tra testing-updates e testing/updates ... 😐 S3v 18:55, 27 set 2014 (CEST)

Nuova sezione mirror

Propongo di spostarla nella voce di glossario Mirror, da trasformarsi in una (mini) guida vera e propria, per tenere traccia della compatibilità con future versioni di Debian dei pacchetti non di sistema utilizzati, come apt-p2p e netselect-apt.

E di utilizzare apt-get invece di aptitude (vedi discussione sul forum), per maggiore compatibilità futura.

HAL 9000 17:52, 26 ott 2015 (CET)

Per me sarebbe meglio creare una guida a parte e lasciare le voci di glossario nel loro stato attuale (appunto come "glossario", spiegazione del termine a cui ci si riferisce). Questo per due motivi:

1. Chi legge vorrebbe sapere cosa significa il termine senza leggersi un'intera guida

2. Si deve necessariamente lasciare un redirect nel caso la guida subisca un cambiamento del titolo ("Mirror" è troppo generico) e a me i redirect non piacciono :)

Quindi, per riassumere, io sono per creare una guida nuova e aggiungere alla pagina "Mirror" un link.

Ho notato però che ultimamente alcune voci di glossario sono diventate vere e proprie guide: mi ripropongo di modificarle e riportarle al loro stato originario oppure di rimuoverle dalla categoria. S3v 19:17, 29 ott 2015 (CET)

Ok, mi sta bene. Direi allora di spostare semplicemente la sezione 3 e farla diventare la sezione 2.3.6 su come scegliere il mirror. Lì si può aggiungere anche un richiamo all'HTTP redirector. In questo modo si può invece togliere quella parte dal glossario.

(Parlando di pagine di glossario, ci sarebbe allora da controllare UUID, che al momento è quasi una miniguida. Forse basta lasciare soltanto l'ultimo dei tre metodi presentati per trovare l'UUID o nemmeno quello.)

HAL 9000 19:51, 29 ott 2015 (CET)

Se c'è materiale a sufficienza sono d'accordo con l'idea di creare una nuova guida solo per i mirrors, non capisco invece che senso avrebbe spostare la sezione mirror di questa guida dentro la sezione esempi configurazioni sempre di questa guida.

Wtf 13:27, 30 ott 2015 (CET)

Per me è indifferente, con creazione di nuova guida o integrazione in questa, quindi come preferisci. :)

Riguardo la mia proposta, quello che volevo proporre è che la tua sezione diventi la 2.3.6, spostando più in basso quella degli esempi, che diventerebbe la 2.3.7.

HAL 9000 13:35, 30 ott 2015 (CET)

Ho rimosso dalla voce di glossario "Mirror" il richiamo ad altri comandi e messo un richiamo alla sezione "Mirrors" di questa guida, dove è stata inserita la descrizione di HTTP Redirector (scritta da BubuXP). Ho aggiunto sia Wtf sia BubuXP tra gli estensori della guida.

Con la nuova lunghezza, penso sia meglio lasciare la sezione nella sua attuale collocazione per non appesantire ulteriormente la parte introduttiva.

HAL 9000 10:47, 1 nov 2015 (CET)

Ottimo Wtf 19:35, 3 nov 2015 (CET)

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)

La pagina è stata aggiornata. HAL 9000 13:01, 18 giu 2017 (CEST)

Discussione:I repository ed il loro utilizzo

Indice