I repository ed il loro utilizzo
|
Versioni Compatibili Tutte le versioni supportate di Debian |
Introduzione
Il repository è a tutti gli effetti un archivio ordinato dove sono raccolti i pacchetti Debian (siano essi pacchetti binari o sorgenti) in modo ben organizzato e costantemente aggiornato. In ogni sistema Debian i repository utilizzati vengono indicati nel file /etc/apt/sources.list
. Vedi anche FAQ: Cos'è un repository?.
La Struttura dei repository
Un repository è suddivisibile, grossomodo, in due sezioni:
- dists in questo ramo sono contenuti i file di controllo, che permettono il funzionamento del sistema di pacchettizzazione. Infatti sono presenti i file che descrivono i pacchetti presenti nell'archivio (divisi per la release di appartenenza);
- doc raccoglie la documentazione di base per Debian (segnalazioni di Bug, Faq, il Contratto Sociale ed altro);
- indices contiene l'indice di tutti i file contenuti in tutti i pacchetti. Queste informazioni sono usate da
apt-file
; - non-US a causa di problemi legali dovuti al divieto di esportazione di materiale per la difesa (tra cui materiale crittografici, utilizzati anche in PGP e SSH). Per ovviare a questi problemi, i pacchetti sono stati posti in una sezione a parte, la cui distribuzione è legata a server non statunitensi;
- pool questo è l'archivio vero e proprio, dove sono contenuti i pacchetti, raggruppati per lettera iniziale;
- project contiene materiale per sviluppatori. Degne di nota la directory experimental, che contiene i pacchetti in fase di sviluppo e perfezionamento;
- tools contiene degli strumenti Dos per la creazione di dischetti di boot, partizionamento e lancio di Linux.
Il file "Release"
Ogni repository contiene un file "Release" contenente diversi informazioni fondamentali per l'utilizzo da parte di APT. Di seguito un paio di esempi
Origin: Unofficial Multimedia Packages Label: Unofficial Multimedia Packages Suite: unstable Version: None Codename: sid Date: Thu, 09 May 2013 21:26:40 UTC Architectures: amd64 armel armhf i386 ia64 mips mipsel powerpc sparc kfreebsd-i386 kfreebsd-amd64 Components: main non-free Description: This repository is mostly non-free # cat liquorix.net_debian_dists_sid_InRelease Origin: liquorix Label: cool stuff Suite: unstable Codename: sid Date: Fri, 03 May 2013 00:32:30 UTC Architectures: i386 amd64 Components: main future past Description: liquorix repository
Dove:
- Origin specifica il proprietario del repository. Se si fa uso del pinning si può sfruttare questo dato inserendo la riga
Pin: release o=
Inpreferences
. - Label identifica il repository: potete inserire descrizioni, ecc. Se si fa uso del pinning si può sfruttare questo dato inserendo la riga
Pin: release l=
Inpreferences
. - Suite (o anche Archive) è l'archivio Debian a cui i pacchetti appartengono (ad es.: stable, testing. ecc.). Se si fa uso del pinning si può sfruttare questo dato inserendo la riga
Pin: release a=
Inpreferences
. - Codename specifica il nome in codice della release. Se si fa uso del pinning si può sfruttare questo dato inserendo la riga
Pin: release n=
Inpreferences
. - Architectures elenca le architetture dei pacchetti contenuti nel repository (ad es.: i386, sparc, source, ecc.).
- Components indica il tipo di componente (ad es.: main, contrib, non-free);
Le sezioni dei repository
Navigando un po' tra gli archivi Debian, si nota subito una particolare suddivisione: i repository, infatti, sono divisi in main, contrib e non-free, nel modo seguente:
- main è la sezione principale, che contiene il 90% dei pacchetti presenti in Debian;
- contrib raccoglie i pacchetti coerenti con i punti 5 e/o 6 delle DFSG, ma che dipendono da pacchetti che non la rispettano;
- non-free contiene dei pacchetti che possiedono delle limitazioni nella distribuzione (ad esempio perché non utilizzabili in ambito commerciale o perché dipendenti da applicazioni o pacchetti che non rispettano la Debian Free Software Guidelines)
Nota che... ...Debian promuove e percorre il sentiero del software totalmente libero; l'uso delle sezioni contrib e non-free è una scelta personale e non un obbligo. |
Sources.list
La gestione dei repository avviene principalmente tramite modifiche al file /etc/apt/sources.list
, questo è forse il più importante file di configurazione del sistema di gestione dei pacchetti Debian; contiene infatti l'elenco e gli indirizzi dei repository a cui apt accede.
Ordine di Inserimento
È importante inserire i repository con un giusto ordine: i primi in elenco, infatti, sono i più importanti (o favoriti). Per migliorare le performance, è consigliabile ordinarli per velocità (es. prima il CD-ROM, poi la rete locale, poi internet, ecc.).
Se non si hanno esigenze particolari, gli utenti che installano Debian da CD o DVD possono cancellare o commentare le righe corrispondenti a queste sorgenti in /etc/apt/sources.list
subito dopo l'installazione. Il motivo è dovuto al fatto che i pacchetti che si trovano su questi supporti sono rapidamente superati dagli aggiornamenti presenti nei repository ufficiali; questi ultimi, se assenti, vanno ovviamente aggiunti manualmente ad /etc/apt/sources.list
.
Ogni volta che si aggiunge o si rimuove un repository dal file sources.list
è necessario impartire il comando:
# apt-get update
oppure:
# aptitude update
per aggiornare la lista dei pacchetti.
Sintassi
Ogni riga che descrive un repository ha una ben determinata sintassi:
deb[-src] <URI> <distribuzione> [componente/i]
Analizziamo i singoli componenti:
deb o deb-src
: serve ad indicare se il repository indicato contiene pacchetti binari o pacchetti sorgenti (se li contiene entrambi, è necessario specificarlo usando due righe diverse);URI
: indica l'indirizzo a cui è possibile trovare il repository; è possibile scegliere tra i seguenti metodi di accesso ai pacchetti:file
: permette di inserire un repository presente sul disco rigido del computer;cdrom
: permette di inserire un repository presente su un cd-rom;http
: permette di accedere ad un repository tramite il protocollo HTTP (se è impostata una variabile di ambientehttp_proxy
col formatohttp://server:port/
verranno usate queste opzioni per accedere al repository; in caso di necessità di autenticazione, è possibile specificare l'indirizzo del proxy, nella variabile d'ambientehttp_proxy
, nel seguente modo:http://user:pass@server:port/
, anche se risulta non essere un modo sicuro di autenticazione);ftp
: permette di accedere ad un repository tramite il protocollo FTP; è possibile specificare un proxy nello stesso modo indicato per http al punto precedente, sostituendo alla variabilehttp_proxy
ftp_proxy
;copy
: è identico a file, ma i file utilizzati vengono salvati nella cache di apt; utile nel caso di supporti removibili quali chiavette USB, floppy, memorie SD, ecc.;rsh, ssh
: permette di accedere ad un repository tramite il protocollo SSH. Non è possibile, però, effettuare alcuna autenticazione interattiva, ma solo tramite lo scambio di chiavi RSA;
distribuzione
: indica la distribuzione (o release) utilizzata, è possibile usare il nome in codice (lenny
,squeeze
,sid
) o il nome generico (stable
,testing
,unstable
);componente/i
: indica le sezioni (main
,contrib
,non-free
) del repository da inserire; sono possibili scelte multiple.
Alcuni esempi
Non c'è niente di meglio, per capire la sintassi del file sources.list
, di un po' di esempi.
I repository ufficiali (binari e sorgenti) presi da un mirror italiano:
deb http://ftp.it.debian.org/debian/ stable main deb-src http://ftp.it.debian.org/debian/ stable main
Ecco come invece si presenta la riga se si sceglie di aggiungere le sezioni contenenti software non totalmente libero.
solo contrib:
deb http://ftp.it.debian.org/debian/ stable main contrib deb-src http://ftp.it.debian.org/debian/ stable main contrib
anche non-free:
deb http://ftp.it.debian.org/debian/ stable main contrib non-free deb-src http://ftp.it.debian.org/debian/ stable main contrib non-free
Il repository di apt-build:
deb file:/var/cache/apt-build/repository apt-build main
Un repository 'artigianale' accessibile tramite un webserver:
deb http://repos.debianizzati.org ./
Un repository situato nella home dell'utente maxer, creato con dpkg-scanpackages
:
deb file:/home/maxer/repos ./
Per altri repository vedere: Lista repository ufficiali Debian e Repository non ufficiali.
Sources.list aggiuntivi
A volte può capitare di avere l'esigenza di avere più di un file contenente la lista dei repository da cui scaricare i pacchetti. Questo può capitare nel caso il file sources.list
inizi a contenere un numero molto elevato di righe oppure perché si vogliono utilizzare dei repository diversi per le normali operazioni sui pacchetti.
Per far ciò è possibile creare dei semplici file di testo, contenenti gli indirizzi dei repository, nella directory /etc/apt/sources.list.d
. La sintassi da utilizzare al loro interno è uguale a quella del file sources.list
; si può scegliere liberamente il nome da assegnare ai file purché termini con l'estensione .list
Una volta creati i file aggiuntivi, questi verranno considerati da APT come se le righe al loro interno fossero presenti all'interno del file sources.list
.
È possibile anche specificare un file, contenente gli indirizzi dei repository, che non si trova all'interno della directory /etc/apt/sources.list.d
. Ad esempio, se il repository da cui abitualmente scarichiamo/aggiorniamo i pacchetti è irraggiungibile, basta creare un file (nell'esempio chiamato nomefile.list
) contenente dei repository appartenenti ad un diverso mirror ed eseguire:
# apt-get -o Dir::Etc::SourceList=/percorso/del/file/nomefile.list update
Bisogna specificare obbligatoriamente il percorso completo del file se questo non si trova nella directory /etc/apt/sources.list.d
Pinning
Introduzione
Come molti sapranno, esistono tre distribuzioni di Debian (chiamate anche release):
- Debian stable, attualmente Wheezy;
- Debian testing, attualmente Jessie;
- Debian unstable, attualmente (e sempre, un nome fisso) Sid.
Il software della stable non viene aggiornato, eccezion fatta per gli aggiornamenti della sicurezza; il software della testing e della unstable viene al contrario aggiornato frequentemente, con una maggiore frequenza per la unstable. Oltre queste tre, ci sarebbero anche la oldstable (la vecchia stable, precedente all’attuale stable) e la experimental che non è una versione completa e funzionante di Debian, ma solo un repository contenente vario software in fase di progettazione, da sperimentare o altamente instabile, dal quale si può attingere dalle altre versioni ma a proprio rischio.
Spesso accade che utilizzando la testing o ancor di più la stable si voglia del software più nuovo rispetto a quello in dotazione; o che al contrario, utilizzando la testing o ancor di più la unstable si voglia del software più stabile rispetto a quello in dotazione. Qui entra in gioco il pinning dei repository, o meglio “tra i repository”, che permette di installare con semplicità del software appartenente a una distribuzione di Debian diversa da quella in uso o anche solo appartenente alla stessa distribuzione, ma proveniente da un altro repository.Tutto ciò riducendo al minimo (posto di sapere quel che si fa) il rischio di creare problemi nel sistema e nel gestore dei pacchetti.
ATTENZIONE Installare pacchetti provenienti da distribuzioni e/o fonti differenti è sempre e comunque fonte di possibili rischi, anche se piccoli |
Prima di procedere nella descrizione operativa del pinning è fondamentale capire come gestisce la priorità dei pacchetti APT e sapere che:
- Col termine distribuzione si intendono stable, testing e unstable. Ciascuna distribuzione ha un suo singolo repository (fonte) principale (due se si conteggia anche l'eventuale repository dedicato agli aggiornamenti di sicurezza) che è quello automaticamente dichiarato dall'installer di debian, ma si tenga presente che ogni distribuzione può avere più fonti sia ufficiali che non ufficiali.
- Col termine fonti si intendono genericamente i repository, ufficiali (es. stable, testing, unstable e backports) o meno (es. deb-multimedia), che forniscono pacchetti relativi ad una o più distribuzioni. Ogni fonte può avere più copie di se stesso (mirrors).
Priorità come punteggio
Il concetto di priorità viene gestito attraverso l'assegnazione di un punteggio ai vari pacchetti, sia installati che ancora da installare. Valgono le seguenti regole:
- priorità 100 alla versione dei pacchetti già installati.
- priorità 500 alle versioni che non sono installate e non appartengono alla distribuzione obiettivo, dove con quest'ultimo termine si deve intendere "Default Release", "Target Release".
- priorità 990 alle versioni che non sono installate e appartengono alla distribuzione obiettivo.
Piccolo esempio teorico. Si supponga quanto segue:
- si desidera installare il pacchetto "vattelapesca" appartenente alla propria distribuzione obiettivo, cioè quella che si è installata (si supponga testing);
- il suddetto pacchetto è presente in tre fonti, repoA, repoB, repoC tutte correttamente specificante nel file
source.list
; - tutti i pacchetti presenti in repoA appartengono alla distribuzione obiettivo (testing in questo esempio), in repoB e repoC sono contenuti pacchetti appartenenti ad un'altra distribuzione (ad esempio unstable e stable rispettivamente);
- la versione di "vattelapesca" in repoA è la 1.4, in repoB la 2.0 e in in repoC la 1.1;
- nel sistema è installata la versione 1.3 di "vattelapesca";
- non esiste un file
preferences
o comunque non è stata specificata una priorità per nessuno dei tre rilasci considerati; - non è stato dichiarato il parametro Default Release in un eventuale file
apt.conf
, ovvero non è stata esplicitamente definita una distribuzione obiettivo.
Nel momento in cui l'utente esegue il comando apt-get install vattelapesca
saranno assegnati i seguenti punteggi:
- 500 a "vattelapesca" presente in repoC;
- 500 a "vattelapesca" presente in repoB;
- 500 a "vattelapesca" presente in repoA;
Tutti e tre i pacchetti hanno lo stesso punteggio, ma il pacchetto proveniente da C viene immediatamente scartato perché implicherebbe retrocessione dello stesso (downgrade, il significato delle varie fascie di punteggio sarà spiegato poco più avanti). A questo punto APT sceglierà tra repoA e repoB in base ad un altro criterio, la versione, quindi ad essere installato sarà il pacchetto proveniente da repoB e non da repoA come desiderato.
Il problema evidentemente non può che esplodere quando si esegue il comando apt-get upgrade
(o peggio apt-get dist-upgrade
), cioè quando si tenta di aggiornare tutti i pacchetti di sistema.
La soluzione è, come facilmente intuibile, quella di assegnare manualmente un punteggio ai vari pacchetti, singolarmente o raggruppandoli. Prima però è necessario capire il significato dei vari punteggi (pin). Nel seguito si indicherà col termine "candidato" il pacchetto o gruppo di pacchetti proveniente dalla generica fonte dichiarata nel file sources.list
.
- Pin minore di 0 (negativo), l’installazione del candidato è impedita a priori (salvo apposito comando).
- Pin compreso tra 1 e 99, il candidato sarà installato solo se sono verificate entrambe le seguenti due condizioni: primo non esistono candidati appartenenti ad altre distribuzioni, secondo nel sistema non è già installata una versione (anche inferiore) del candidato.
- Pin compreso tra 100 e 499, il candidato sarà installato solo se non esistono candidati appartenenti ad altre distribuzioni e se la versione eventualmente già installata non è superiore a quella del candidato. Se per esempio il pacchetto "vattelapesca" ha pin 400 ed è presente su due fonti (posto ovviamente di aver dichiarato entrambe nel solito
sources.list
) e ciascuna fonte appartiene ad una distribuzione differente, come stable e testing, allora sarà impossibile installare il suddetto pacchetto, a prescindere dal numero di versione; diversamente se le due fonti appartenessero alla stessa distribuzione allora il pacchetto potrebbe teoricamente essere installato. (NOTA, l'esempio fatto è strettamente teorico e non verificato praticamente). - Pin compreso tra 500 e 989, il candidato sarà installato solo se non esistono candidati appartenenti alla distribuzione obiettivo e se la versione eventualmente già installata non è superiore a quella del candidato. Si noti che il semplice fatto di aver installato una certa distribuzione, per esempio testing, non significa aver definito la distribuzione obiettivo, che può essere solo definita manualmente dall'utente (il come sarà spiegato nella discussione del file
apt.conf
). - Pin compreso tra 990 e 999, il candidato sarà installato solo se non esistono altri candidati con pin maggiore e se la versione eventualmente già installata non è superiore a quella del candidato.
- Pin 1000 o superiore, il candidato sarà installato se non esistono altri candidati con pin maggiore, è quindi possibile la retrocessione di versione (downgrade) se la versione eventualmente già installata è superiore a quella del candidato. Es. è possibile installare la versione 1.1 di un pacchetto anche se ad essere già installata è la 1.2 o superiore.
Nota APT può derogare alle regole generali sopra esposte per soddisfare le varie dipendenze dei pacchetti. |
/etc/apt/apt.conf
Questo file insieme ad altri permette di definire le opzioni di APT e relativi strumenti senza bisogno di digitarli sempre da riga di comando. Si vedano le guide dedicate ad Apt-Get e Aptitude per alcuni brevi esempi contenenti alcui dei parametri più comuni. Per quanto riguarda il pinning l'unico parametro strettamente di rilievo è:
APT::Default-Release "distribuzione_voluta";
che equivale alla dichiarazione in riga di comando dell'opzione -t distribuzione_voluta sia in Apt-Get che Aptitude. Tale dichiarazione attribuisce priorità 990 a tutti i pacchetti appartenenti alla distribuzione specificata
Si noti inoltre che:
- Le dichiarazioni di parametri da riga di comando hanno sempre la precedenza su quelli definiti in un file di configurazione, quindi usare un comando del tipo
apt-get install pacchetto -t distribuzione_taldeitali
sorpassa qualunque distribuzione obiettivo (Default-Release) dichiarata nel fileapt.conf
. - Comandi del tipo
apt-get install pacchetto/distribuzione_taldeitali
non cambiano la target release, ma si limitano a dire di prelevare lo specifico pacchetto dalla distribuzione indicata invece che da quella predefinita. Questo implica che le dipendenze continueranno ad essere risolte in base alla distribuzione obiettivo eventualmente specificata inapt.conf
e/o in base al file preferences e/o in accordo all'algoritmo predefinito. - Definire una distribuzione obiettivo in
apt.conf
è equivalente a dichiarare inpreferences
(si veda la prossima sezione) quanto segue
Package: * Pin: release a=distribuzione_voluta Pin-Priority: 990
- Qualora si sia definita una distribuzione obiettivo in
apt.conf
allora quasiasi dichiarazione inpreferences
riguardante tutti i pacchetti di una certa distribuzione sarà ignorata, ad esempio definire
Package: * Pin: release a=distribuzione_voluta Pin-Priority: 1000
- è del tutto inutile. Non è invece inutile una dichiarazione del seguente tipo:
Package: specifico pacchetto o espressione regolare Pin: release a=distribuzione_voluta Pin-Priority: 1000
/etc/apt/preferences
Questo è il file dove è possibile definire tutte le priorità che si vogliono, fermo restando quanto detto nella sezione dedicata ad apt.conf
. La sintassi generale è la seguente:
Package: nome pacchetto o espressione regolare Pin: parametro da usare per identificare la versione desiderata Pin-Priority: numero
Un paio di esempi del tutto arbitrari:
Package: vlc Pin: release a=testing Pin-Priority: 991 Package: virtualbox4* Pin: Release o=Oracle Corporation Pin-Priority: 780
Nel primo esempio si è definito il pinning per il pacchetto di nome "vlc", richiedendo che le versioni appartenenti alla distribuzione testing abbiano priorità 991. Nel secondo invece sfruttando una semplicissima espressione regolare si impone che tutti i pacchetti il cui nome inizia per "virtualbox4" e appartenenti al repository la cui origine è definita come "Oracle Corporation" abbiano priorità 780.
Il pinning può essere orientato ai campi "Suite", "Origin", "Label" e "Codename" del file "Release" di un certo repository (si veda inizio pagina), nonché all'indirizzo del repository stesso. Si noti che per archivi personali e/o non ufficiali può non essere presente (purtroppo) un file "Release".
È utile infine evidenziare un paragrafo del manuale di apt_preferences:
Suggerimento Specificare nel file sources.list sempre per primi il o i repository principali della distribuzione obiettivo.
|
Esempi
01
La distribuzione principale sia testing, quella secondaria unstable.
sources.list
deb http://ftp.it.debian.org/debian/ testing main contrib non-free deb http://security.debian.org/ testing/updates main contrib non-free deb http://ftp.de.debian.org/debian unstable main contrib non-free
apt.conf
APT { Default-Release "testing"; Cache-Limit 48000000; Get { AllowUnauthenticated 1; AutomaticRemove "true"; Fix-Broken "true"; Purge "true"; Show-Upgraded "true"; } } Aptitude { Autoclean-After-Update "true"; Auto-Fix-Broken "true"; Purge-Unused "true"; }
preferences
Package: * Pin: release a=unstable Pin-Priority: 500 Package: * Pin: release o=Debian Pin-Priority: -10
Conseguenze
Usando le azioni install e upgrade senza specificare l'opzione -t unstable si installano/aggiornano pacchetti prelevando le versioni da testing, a meno che un pacchetto sia presente solo in unstable, nel qual caso sarà prelevato da lì. Le dipendenze saranno risolte se possibile usando testing, altrimenti usando unstable.
Digitando apt-get install vattelapesca -t unstable
si installerà la versione "vattelapesca" appartenente ad unstable, così come le sue dipendenze. Si noti che in questo caso successivi aggiornamenti tramite comandi del tipo apt-get upgrade
o apt-get dist-upgrade
non produrranno alcun aggiornamento da unstable del pacchetto "vattelapesca" se questo è anche presente in testing; in tal caso l'unica possibilità di aggiornare "vattelapesca" è digitare nuovamente apt-get install vattelapesca -t unstable
.
02
In questo how-to mostrerò come utilizzare pacchetti Debian provenienti da Testing, Unstable, Experimental e deb-multimedia (audio/video) ma le istruzioni sono facilmente riportabili anche ad altre situazioni (unstable + experimental, stable + testing, stable + unstable, stable + testing + unstable, ecc.).
Impostare i repository
Assicuriamoci di essere l'utente root e procediamo.
Per prima cosa editiamo il file /etc/apt/sources.list
ed inseriamo gli archivi dei pacchetti Debian che utilizzeremo, per esempio:
### Debian Ufficiale -- Testing deb http://ftp.it.debian.org/debian/ testing main contrib non-free ### Debian Ufficiale -- Testing Sicurezza deb http://security.debian.org/ testing/updates main contrib non-free ### Debian Ufficiale -- Sid deb http://ftp.it.debian.org/debian/ unstable main contrib non-free ### Debian Ufficiale -- Experimental deb http://ftp.it.debian.org/debian/ experimental main contrib non-free ### deb-multimedia -- Audio/Video -- Marillat deb http://www.deb-multimedia.org testing main non-free deb http://www.deb-multimedia.org sid main non-free
Configurare apt
A questo punto dobbiamo preparare due file normalmente non presenti sulla nostra debianbox: si tratta dei file /etc/apt/preferences
e /etc/apt/apt.conf
.
Questi due file istruiranno APT su come gestire le dipendenze dei pacchetti, informandolo su come comportarsi in caso di conflitti e altri problemi.
Il file apt.conf
Ora creiamo il file /etc/apt/apt-conf
# touch /etc/apt/apt.conf
ed editiamolo inserendo quanto segue:
APT::Default-Release "testing"; APT::Cache-Limit 15000000; Apt::Get::Purge; APT::Clean-Installed; APT::Get::Fix-Broken; APT::Get::Fix-Missing; APT::Get::Show-Upgraded "true";
Il file preferences
Creiamo il file /etc/apt/preferences
:
# touch /etc/apt/preferences
ed editiamolo col nostro editor di fiducia e inseriamo queste direttive:
Package: * Pin: release o=Unofficial Multimedia Packages Pin-Priority: 950 Package: * Pin: release a=unstable Pin-Priority: 800 Package: * Pin: release a=experimental Pin-Priority: 750
Facciamo l'update del database dei pacchetti:
# apt-get update
D'ora in avanti avremo due possibilità per installare un nuovo pacchetto: il metodo che usiamo di solito e cioè:
# apt-get install nome_pacchetto
che utilizzerà pacchetti proveniente dalla versione impostata come Default-Release in apt.conf, oppure il comando
# apt-get install -t versione_di_debian nome_pacchetto
che provvederà a installare il pacchetto da noi richiesto per la versione specificata (versione_debian), risolvendo automaticamente le dipendenze.
Approfondimenti
Manpages
man apt.conf
man apt_preferences
Sitografia
- Parte di quanto scritto nella sezione dedicata al pinning è materiale tratto dalla guida originale pubblicata su www.mirkopagliai.it, distribuita secondo licenza originale CC.
Guida scritta da: MaXeR | Guida Debianized |
Estesa da: | |
Verificata da: | |
Verificare ed estendere la guida | Cos'è una guida Debianized |