Gestione dei metapacchetti: differenze tra le versioni
S3v (discussione | contributi) |
(aggiunte, ma ancora da verificare il resto) |
||
| Riga 2: | Riga 2: | ||
== Cosa sono i metapacchetti == | == Cosa sono i metapacchetti == | ||
Esiste un tipo particolare di pacchetto detto [[metapacchetto]] che in realtà non contiene alcun eseguibile o sorgente, ma serve semplicemente per installare tutto l'insieme di pacchetti (spesso a loro volta metapacchetti) che lo costituisce.<br/> | Esiste un tipo particolare di pacchetto detto [[metapacchetto]] che in realtà non contiene alcun eseguibile o sorgente, ma serve semplicemente per installare tutto l'insieme di pacchetti (spesso a loro volta metapacchetti) che lo costituisce.<br/> | ||
Un esempio è il [[pacchetto]] "kde-full" che permette di installare l'intero ambiente KDE in un colpo solo. Scarichiamo il pacchetto: | Un esempio è il [[pacchetto]] "kde-full" che permette di installare l'intero ambiente KDE in un colpo solo. Scarichiamo il pacchetto con [[apt-get]]: | ||
<pre> | <pre> | ||
$ apt-get download kde-full | $ apt-get download kde-full | ||
| Riga 12: | Riga 12: | ||
</pre> | </pre> | ||
Già le dimensioni lasciano presagire qualcosa: come può un pacchetto come "kde-full" occupare solo poco meno di 12 KB? Vediamo cosa contiene: | Già le dimensioni lasciano presagire qualcosa: come può un pacchetto come "kde-full" occupare solo poco meno di 12 KB? Vediamo cosa contiene con [[dpkg]]: | ||
<pre> | <pre> | ||
$ dpkg- | $ dpkg --contents kde-full_77+deb7u1_all.deb | ||
drwxr-xr-x root/root 0 2013-04-19 01:18 ./ | drwxr-xr-x root/root 0 2013-04-19 01:18 ./ | ||
drwxr-xr-x root/root 0 2013-04-19 01:18 ./usr/ | drwxr-xr-x root/root 0 2013-04-19 01:18 ./usr/ | ||
| Riga 29: | Riga 29: | ||
<pre> | <pre> | ||
$ dpkg- | $ dpkg --info kde-full_77+deb7u1_all.deb | ||
nuovo pacchetto debian, versione 2.0. | nuovo pacchetto debian, versione 2.0. | ||
dimensione 11732 byte: archivio di controllo=888 byte. | dimensione 11732 byte: archivio di controllo=888 byte. | ||
| Riga 61: | Riga 61: | ||
== Lista dei metapacchetti == | == Lista dei metapacchetti == | ||
Si può ottenere una lista completa dei metapacchetti elencando i pacchetti che contengono la parola ''metapackage'' nei [[tag]], nelle descrizioni oppure che appartengono alla sezione "metapackages"; servirà il pacchetto "debtags": | Si può ottenere una lista completa dei metapacchetti elencando i pacchetti che contengono la parola ''metapackage'' nei [[tag]], nelle descrizioni oppure che appartengono alla sezione "metapackages"; servirà il pacchetto "debtags" e l'uso di [[aptitude]]: | ||
<pre> | <pre> | ||
$ aptitude search '(~Gmetapackage|~dmetapackage|~smetapackages)' | less | $ aptitude search '(~Gmetapackage|~dmetapackage|~smetapackages)' | less | ||
| Riga 74: | Riga 74: | ||
A questi si aggiungono le eccezioni comprendenti i metapacchetti che riguardano l'installazione del kernel; questi sono nella forma: <code>linux-image-*</code> | A questi si aggiungono le eccezioni comprendenti i metapacchetti che riguardano l'installazione del kernel; questi sono nella forma: <code>linux-image-*</code> | ||
<pre> | <pre> | ||
$ aptitude search ~nlinux-image-* | $ aptitude search '~nlinux-image-*' | ||
</pre> | </pre> | ||
che sono dei metapacchetti che dipendono sempre dall'ultimo kernel Linux disponibile per la sotto-architettura specificata. In tal modo, installando il pacchetto adatto al proprio sistema, il kernel verrà automaticamente aggiornato non appena sia disponibile una nuova versione (si passerà ad esempio dal 2.6.15 a 2.6.17). Viceversa, se non si installa il metapacchetto, il kernel non verrà mai aggiornato poiché i kernel Debian hanno la versione come parte integrante del nome del pacchetto e quindi una nuova versione viene vista come un nuovo pacchetto e non come un aggiornamento, come giusto che sia. | che sono dei metapacchetti che dipendono sempre dall'ultimo kernel Linux disponibile per la sotto-architettura specificata. In tal modo, installando il pacchetto adatto al proprio sistema, il kernel verrà automaticamente aggiornato non appena sia disponibile una nuova versione (si passerà ad esempio dal 2.6.15 a 2.6.17). Viceversa, se non si installa il metapacchetto, il kernel non verrà mai aggiornato poiché i kernel Debian hanno la versione come parte integrante del nome del pacchetto e quindi una nuova versione viene vista come un nuovo pacchetto e non come un aggiornamento, come giusto che sia. | ||
| Riga 98: | Riga 98: | ||
=== Rimuovere l'intera ''suite'' === | === Rimuovere l'intera ''suite'' === | ||
Se vogliamo semplicemente eliminare tutta la ''suite'' del metapacchetto andremo semplicemente a rimuoverlo con il nostro gestore preferito. Nel caso di ''aptitude'', provvederà lui stesso ad eliminare le dipendenze (dunque i pacchetti della ''suite''); nel caso di apt-get, dopo il classico | Se vogliamo semplicemente eliminare tutta la ''suite'' del metapacchetto andremo semplicemente a rimuoverlo con il nostro gestore preferito. Nel caso di ''aptitude'', provvederà lui stesso ad eliminare le dipendenze (dunque i pacchetti della ''suite''); nel caso di [[apt-get]], dopo il classico | ||
<pre># apt-get | <pre># apt-get remove nomemetapacchetto</pre> | ||
dovremo eseguire ancora: | dovremo eseguire ancora: | ||
| Riga 129: | Riga 129: | ||
</pre> | </pre> | ||
Quindi rimuoviamo il pacchetto che ci interessa: | Quindi rimuoviamo il pacchetto che ci interessa: | ||
<pre># apt-get | <pre># apt-get remove evolution</pre> | ||
Lanciato il comando, verremo avvertiti che saranno eliminati cinque pacchetti: ''gnome'', ''gnome-desktop-environment'', ''evolution'', ''evolution-exchange'', ''evolution-plugins'', tra i quali noteremo i due metapacchetti della ''suite'' in questione. Lo stesso ''apt-get'' ci suggerirà poi di utilizzare ''apt-get autoremove'' per eliminare le dipendenze non soddisfatte (che sono però in questo caso tutti i pacchetti della ''suite''). Per mantenere questi pacchetti daremo il comando: | Lanciato il comando, verremo avvertiti che saranno eliminati cinque pacchetti: ''gnome'', ''gnome-desktop-environment'', ''evolution'', ''evolution-exchange'', ''evolution-plugins'', tra i quali noteremo i due metapacchetti della ''suite'' in questione. Lo stesso ''apt-get'' ci suggerirà poi di utilizzare ''apt-get autoremove'' per eliminare le dipendenze non soddisfatte (che sono però in questo caso tutti i pacchetti della ''suite''). Per mantenere questi pacchetti daremo il comando: | ||
| Riga 150: | Riga 150: | ||
Come noto i metapacchetti sono molto utili per installare ''suite'' di programmi con un solo comando (installando il metapacchetto appunto). Con il pacchetto '''equivs''' tutto è molto semplice; incominceremo con l'installarlo: | Come noto i metapacchetti sono molto utili per installare ''suite'' di programmi con un solo comando (installando il metapacchetto appunto). Con il pacchetto '''equivs''' tutto è molto semplice; incominceremo con l'installarlo: | ||
<pre># | <pre># apt-get install equivs</pre> | ||
A questo punto lanceremo il comando: | A questo punto lanceremo il comando: | ||
| Riga 191: | Riga 191: | ||
<pre>$ equivs-build controller</pre> | <pre>$ equivs-build controller</pre> | ||
che creerà il metapacchetto <code>.deb</code> che potremo poi installare come qualsiasi pacchetto | che creerà il metapacchetto <code>.deb</code> che potremo poi installare come qualsiasi pacchetto. | ||
{{Warningbox | È possibile anche creare un metapacchetto con il nome e la versione di una dipendenza da soddisfare, ingannando così il sistema, che penserà che una data dipendenza è già soddisfatta e non cercherà quindi di installarla. Questo uso è però pericoloso, se non si è più che certi di quello che si sta facendo, e nel caso peggiore può rendere inusabile tanto il programma quanto l'intero sistema.}} | |||
=== Esempio pratico === | === Esempio pratico === | ||
| Riga 251: | Riga 254: | ||
Ricordiamo di aggiungere i repository debian-multimedia (deb http://www.debian-multimedia.org lenny main) all'interno del proprio /etc/apt/sources.list</pre> | Ricordiamo di aggiungere i repository debian-multimedia (deb http://www.debian-multimedia.org lenny main) all'interno del proprio /etc/apt/sources.list</pre> | ||
Si ricordi che <code>dpkg</code> non si occupa di risolvere le dipendenze, quindi installare un pacchetto con dipendenze non soddisfatte ne aggiungerebbe uno con stato ''broken'' al sistema, che andrebbe corretto in seguito (per esempio con <code>apt-get --fix-broken</code>). È però consigliato utilizzare [[gdebi]], che si avvale subito di [[APT]] per cercare di risolvere le dipendenze del pacchetto prima di procedere alla sua installazione, evitando di installare pacchetti ''broken'' sul sistema. | |||
{{Autori | {{Autori | ||
Versione delle 08:30, 7 mag 2015
 Versioni Compatibili Tutte le versioni supportate di Debian |
Cosa sono i metapacchetti
Esiste un tipo particolare di pacchetto detto metapacchetto che in realtà non contiene alcun eseguibile o sorgente, ma serve semplicemente per installare tutto l'insieme di pacchetti (spesso a loro volta metapacchetti) che lo costituisce.
Un esempio è il pacchetto "kde-full" che permette di installare l'intero ambiente KDE in un colpo solo. Scarichiamo il pacchetto con apt-get:
$ apt-get download kde-full
e controlliamo la sua dimensione:
$ ls -l kde-full* -rw-r--r-- 1 pippo pippo 11732 apr 19 2013 kde-full_77+deb7u1_all.deb
Già le dimensioni lasciano presagire qualcosa: come può un pacchetto come "kde-full" occupare solo poco meno di 12 KB? Vediamo cosa contiene con dpkg:
$ dpkg --contents kde-full_77+deb7u1_all.deb drwxr-xr-x root/root 0 2013-04-19 01:18 ./ drwxr-xr-x root/root 0 2013-04-19 01:18 ./usr/ drwxr-xr-x root/root 0 2013-04-19 01:18 ./usr/share/ drwxr-xr-x root/root 0 2013-04-19 01:18 ./usr/share/doc/ drwxr-xr-x root/root 0 2013-04-19 01:18 ./usr/share/doc/kde-full/ -rw-r--r-- root/root 1038 2013-03-25 19:44 ./usr/share/doc/kde-full/copyright -rw-r--r-- root/root 9582 2013-04-19 01:18 ./usr/share/doc/kde-full/changelog.gz
L'archivio data.tar.gz contiene solo due file.
Diamo un'occhiata al file control:
$ dpkg --info kde-full_77+deb7u1_all.deb
nuovo pacchetto debian, versione 2.0.
dimensione 11732 byte: archivio di controllo=888 byte.
1332 byte, 23 righe control
137 byte, 2 righe md5sums
Package: kde-full
Source: meta-kde
Version: 5:77+deb7u1
Architecture: all
Maintainer: Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
Installed-Size: 35
Depends: kde-plasma-desktop (>= 5:77+deb7u1), kde-plasma-netbook (>= 5:77+deb7u1), kdeadmin (>= 4:4.8.4), kdeartwork (>= 4:4.8.4), kdegraphics (>= 4:4.8.4),
kdeedu (>= 4:4.8.4), kdegames (>= 4:4.8.4), kdemultimedia (>= 4:4.8.4), kdenetwork (>= 4:4.8.4), kdeutils (>= 4:4.8.4), kdepim (>= 4:4.4.11),
kdeplasma-addons (>= 4:4.8.4)
Recommends: kde-standard (>= 5:77+deb7u1), kdeaccessibility (>= 4:4.8.4), kdesdk (>= 4:4.8.4), kdetoys (>= 4:4.8.4), kdewebdev (>= 4:4.8.4)
Suggests: kde-l10n (>= 4:4.8.4), calligra (>= 1:2.4.2), xorg
Breaks: kde-minimal (<< 5:57)
Provides: kde-software-compilation
Section: metapackages
Priority: optional
Homepage: http://www.kde.org
Description: ...
In realtà, vediamo che a costituire il cuore del pacchetto sono le sue dipendenze (a loro volta metapacchetti). Questo permette di installare KDE attraverso l'installazione di un solo pacchetto. Senza i metapacchetti bisognerebbe installare uno per uno i pacchetti che costituiscono KDE.
L'output precedente indica chiaramente che il pacchetto "kde-full" è in realtà un metapacchetto:
Section: metapackages
Lista dei metapacchetti
Si può ottenere una lista completa dei metapacchetti elencando i pacchetti che contengono la parola metapackage nei tag, nelle descrizioni oppure che appartengono alla sezione "metapackages"; servirà il pacchetto "debtags" e l'uso di aptitude:
$ aptitude search '(~Gmetapackage|~dmetapackage|~smetapackages)' | less
Se si vuole avere invece una lista dei metapacchetti installati sul sistema:
$ aptitude search '~i(~Gmetapackage|~dmetapackage|~smetapackages)'
|
ATTENZIONE La ricerca della parola "metapackage" nelle descrizioni potrebbe fornire dei "falsi positivi". Indirizzarsi su una ricerca basata solo sui tag o sulla sezione del pacchetto: $ aptitude search '~i(~Gmetapackage|~smetapackages)'per evitare problemi oppure leggere con attenzione la descrizione del pacchetto: $ apt-cache show nomepacchetto |
A questi si aggiungono le eccezioni comprendenti i metapacchetti che riguardano l'installazione del kernel; questi sono nella forma: linux-image-*
$ aptitude search '~nlinux-image-*'
che sono dei metapacchetti che dipendono sempre dall'ultimo kernel Linux disponibile per la sotto-architettura specificata. In tal modo, installando il pacchetto adatto al proprio sistema, il kernel verrà automaticamente aggiornato non appena sia disponibile una nuova versione (si passerà ad esempio dal 2.6.15 a 2.6.17). Viceversa, se non si installa il metapacchetto, il kernel non verrà mai aggiornato poiché i kernel Debian hanno la versione come parte integrante del nome del pacchetto e quindi una nuova versione viene vista come un nuovo pacchetto e non come un aggiornamento, come giusto che sia.
Installazione/Rimozione
Capito cosa sono i metapacchetti, ci accorgeremo subito di un problema: se per l'installazione di una suite, come ad esempio GNOME, l'installazione di un solo metapacchetto ci permette l'installazione di tutti i pacchetti necessari, essendo quest'ultimi tutte dipendenze del metapacchetto, se si andrà a rimuovere un pacchetto della suite in questione, il metapacchetto precedentemente installato avrà una dipendenza non soddisfatta. Questo farà sì che ad esempio Aptitude rimuoverà tutti i pacchetti della suite in quanto risultanti come dipendenze di un pacchetto che non è più installato (il metapacchetto appunto); altri comandi, come ad esempio:
# apt-get autoremove
porteranno allo stesso risultato, sempre per via di dipendenze installate per un pacchetto che non esiste più.
|
NOTA BENE: questo comportamento dei pacchetti è in realtà un sistema molto ben architettato per "pulire" il sistema da pacchetti "inutili" (o meglio, per meglio dire, non più utili). Ad esempio: se ho installato il pacchetto Y per soddisfare una dipendenza del pacchetto X, eliminato X il pacchetto Y non mi servirà più, essendo stato installato unicamente per far funzionare X. Immaginando di aver appena eliminato il pacchetto X, Aptitude andrà automaticamente ad eliminare il pacchetto Y "ricordandosi" di averlo installato come dipendenza del pacchetto X. apt-get autoremove "vedrà" il pacchetto Y come installato da dipendenza e lo eliminerà portando allo stesso risultato.
|
Installare un metapacchetto
In questo caso non occorre nessuna attenzione particolare: installeremo il metapacchetto come qualsiasi altro pacchetto con il nostro gestore preferito (aptitude, apt-get, synaptic, etc.), il quale si "porterà dietro" tutti i pacchetti del caso (come sue dipendenze).
Rimuovere un metapacchetto
Il problema di quest'azione è riassunto all'inizio di questo capitolo.
Rimuovere l'intera suite
Se vogliamo semplicemente eliminare tutta la suite del metapacchetto andremo semplicemente a rimuoverlo con il nostro gestore preferito. Nel caso di aptitude, provvederà lui stesso ad eliminare le dipendenze (dunque i pacchetti della suite); nel caso di apt-get, dopo il classico
# apt-get remove nomemetapacchetto
dovremo eseguire ancora:
# apt-get autoremove
proprio per rimuovere le dipendenze installate per il metapacchetto.
Rimuovere uno o più pacchetti della suite
In questo caso, come già detto in precedenza, la rimozione di uno o più pacchetti della suite, porterà alla rimozione del metapacchetto principale (essendo esso stesso senza una o più dipendenze soddisfatte). A questo punto, senza il metapacchetto che faceva da "scheletro" alla suite, i pacchetti di quest'ultima verranno eliminati da aptitude o da apt-get autoremove.
Per eliminare dunque dei pacchetti da una suite utilizzeremo apt-get e aptitude in modo combinato. Facciamo un esempio:
- come suite prenderemo GNOME. I metapacchetti che la installano sono gnome e gnome-desktop-environment
- andremo ad eliminare il pacchetto evolution della suite, senza eliminare quest'ultima.
Inizieremo innanzitutto ad aggiornare il sistema per prevenire sopraggiunte modifiche nelle dipendenze tra pacchetti:
# apt-get update
e poi:
# apt-get upgrade
oppure:
# apt-get dist-upgrade
Quindi rimuoviamo il pacchetto che ci interessa:
# apt-get remove evolution
Lanciato il comando, verremo avvertiti che saranno eliminati cinque pacchetti: gnome, gnome-desktop-environment, evolution, evolution-exchange, evolution-plugins, tra i quali noteremo i due metapacchetti della suite in questione. Lo stesso apt-get ci suggerirà poi di utilizzare apt-get autoremove per eliminare le dipendenze non soddisfatte (che sono però in questo caso tutti i pacchetti della suite). Per mantenere questi pacchetti daremo il comando:
# aptitude keep-all
che andrà ad eliminare la loro eliminazione (scusate il gioco di parole). L'opzione keep-all di aptitude cancella tutte le azioni impostate per ogni pacchetto; qualsiasi azione d'installazione, rimozione o aggiornamento verrà rimossa dallo stato di tutti i pacchetti interessati.
Un risultato identico si ottiene con apt-mark:
# apt-mark manual pacchetto1 pacchetto2 pacchetto3 ...
che marcherà il pacchetto (o i pacchetti) come "manual" al posto di "auto". Questo eviterà che "autoremove" lo consideri come pacchetto da disinstallare.
"apt-mark", a differenza di "aptitude keep-all", necessita che il nome dei pacchetti sia specificato esplicitamente.
A questo punto, avremo la nostra suite perfettamente funzionante con le "modifiche" apportate.
Creare un metapacchetto
Come noto i metapacchetti sono molto utili per installare suite di programmi con un solo comando (installando il metapacchetto appunto). Con il pacchetto equivs tutto è molto semplice; incominceremo con l'installarlo:
# apt-get install equivs
A questo punto lanceremo il comando:
$ equivs-control controller
il quale creerà un file controller per il nostro metapacchetto (il nome è arbitrario, potete scegliere quello che volete). Il suo aspetto è il seguente (dopo averlo aperto in un editor qualsiasi):
### Commented entries have reasonable defaults. ### Uncomment to edit them. Section: misc Priority: optional Standards-Version: 3.6.2 Package: <package name; defaults to equivs-dummy> # Version: <enter version here; defaults to 1.0> # Maintainer: Your Name <yourname@example.com> # Pre-Depends: <comma-separated list of packages> # Depends: <comma-separated list of packages> # Recommends: <comma-separated list of packages> # Suggests: <comma-separated list of packages> # Provides: <comma-separated list of packages> # Replaces: <comma-separated list of packages> # Architecture: all # Copyright: <copyright file; defaults to GPL2> # Changelog: <changelog file; defaults to a generic changelog> # Readme: <README.Debian file; defaults to a generic one> # Extra-Files: <comma-separated list of additional files for the doc directory> Description: <short description; defaults to some wise words> long description and info . second paragraph
Andremo poi ad inserire i campi illustrati dopo aver decommentato le righe che vogliamo definire. Il campo più importante è sicuramente Depends, che ha il ruolo fondamentale del metapacchetto, senza dimenticarci di dare il nome al metapacchetto. Gli altri campi sono più o meno facoltativi (inserire la versione, il mantenitore e una piccola descrizione sarebbe comunque auspicato).
Infine daremo il comando:
$ equivs-build controller
che creerà il metapacchetto .deb che potremo poi installare come qualsiasi pacchetto.
|
|
ATTENZIONE È possibile anche creare un metapacchetto con il nome e la versione di una dipendenza da soddisfare, ingannando così il sistema, che penserà che una data dipendenza è già soddisfatta e non cercherà quindi di installarla. Questo uso è però pericoloso, se non si è più che certi di quello che si sta facendo, e nel caso peggiore può rendere inusabile tanto il programma quanto l'intero sistema. |
Esempio pratico
Prendiamo ad esempio questa guida: Installare e configurare i codec per DVD e Mp3. Sarebbe ora interessante creare un metapacchetto che installi i pacchetti necessari con un solo comando. Iniziamo dunque a creare un controller:
$ equivs-control controller
Editiamo poi il file controller nel modo seguente (sulla base della guida citata):
### Commented entries have reasonable defaults. ### Uncomment to edit them. Section: misc Priority: optional Standards-Version: 3.6.2 Package: codec-dvd-mp3 Version: 0.1 Maintainer: Debianizzati <info@debianizzati.org> # Pre-Depends: <comma-separated list of packages> Depends: libfaad2-0,libmp4-0,libfaac0,alsamixergui,toolame,lame,libmp3lame0,libdvdnav4,libdvdread3,libdvdcss2,w32codecs,ffmpeg Recommends: debian-multimedia-keyring # Suggests: <comma-separated list of packages> # Provides: <comma-separated list of packages> # Replaces: <comma-separated list of packages> # Architecture: all # Copyright: <copyright file; defaults to GPL2> # Changelog: <changelog file; defaults to a generic changelog> # Readme: <README.Debian file; defaults to a generic one> # Extra-Files: <comma-separated list of additional files for the doc directory> Description: installa codec per DVD e mp3 Questo metapacchetto installa le librerie per la riproduzione di DVD e mp3. Ricordiamo di aggiungere i repository debian-multimedia (deb http://www.debian-multimedia.org lenny main) all'interno del proprio /etc/apt/sources.list
Creiamo il pacchetto Debian:
$ equivs-build controller
Se tutto sarà andato a buon fine (occhio alla sintassi!) otterremo il pacchetto codec-dvd-mp3_0.1_all.deb nella directory da dove abbiamo lanciato i comandi. Per eseguire un'ennesima verifica del pacchetto utilizziamo il comando:
$ dpkg --info codec-dvd-mp3_0.1_all.deb
ottenendo il seguente output:
Package: codec-dvd-mp3 Version: 0.1 Architecture: all Maintainer: Debianizzati <info@debianizzati.org> Installed-Size: 36 Depends: libfaad2-0, libmp4-0, libfaac0, alsamixergui, toolame, lame, libmp3lame0, libdvdnav4, libdvdread3, libdvdcss2, w32codecs, ffmpeg Recommends: debian-multimedia-keyring Section: misc Priority: optional Description: installa codec per DVD e mp3 Questo metapacchetto installa le librerie per la riproduzione di DVD e mp3. Ricordiamo di aggiungere i repository debian-multimedia (deb http://www.debian-multimedia.org lenny main) all'interno del proprio /etc/apt/sources.list
Si ricordi che dpkg non si occupa di risolvere le dipendenze, quindi installare un pacchetto con dipendenze non soddisfatte ne aggiungerebbe uno con stato broken al sistema, che andrebbe corretto in seguito (per esempio con apt-get --fix-broken). È però consigliato utilizzare gdebi, che si avvale subito di APT per cercare di risolvere le dipendenze del pacchetto prima di procedere alla sua installazione, evitando di installare pacchetti broken sul sistema.
| Guida scritta da: Brunitika 16:49, 8 apr 2009 (CEST) |  Debianized 20%
|
| Estesa da: | |
| Verificata da: | |
|
Verificare ed estendere la guida | Cos'è una guida Debianized | |