Differences between revisions 6 and 7
Revision 6 as of 2013-05-18 18:36:54
Size: 37212
Comment: sync with English master
Revision 7 as of 2013-06-16 15:19:53
Size: 38674
Comment: sync with English master
Deletions are marked like this. Additions are marked like this.
Line 302: Line 302:
<<Anchor(package-many-removals)>>

=== Si è cercato di rimuovere un pacchetto e ora molti altri sono contrassegnati per la rimozione (automatica) ===

Questo solitamente avviene perché si sta tentando di rimuovere un pacchetto che è una dipendenza di un metapacchetto.
In una situazione simile tutti i gestori di pacchetti cercano di rimuovere anche il metapacchetto ma, come conseguenza, tutte le dipendenze del metapacchetto vengono quindi considerate non utilizzate e vengono contrassegnate per la rimozione (automatica). Ci sono vari modi di risolvere un problema simile:

 1.#1. Contrassegnare le altre dipendenze come installate manualmente e lasciare che il gestore dei pacchetti rimuova il metapacchetto.

Questo manterrà installati gli altri pacchetti, ma ha il difetto che le nuove dipendenze del metapacchetto non verranno installate. Questo non è un problema per stable, ma solo per testing, unstable o per gli aggiornamenti ad un nuovo rilascio.

 2.#2. Forzare il gestore dei pacchetti ad ignorare la dipendenza mancante e mantenere installato il metapacchetto.

Questo è pericoloso, a meno di non sapere esattamente ciò che si sta facendo e il gestore dei pacchetti continuerà a lamentarsi dei pacchetti difettosi. Vedere il prossimo punto per una soluzione migliore.

 3.#3. Usaree "equivs" per creare un pacchetto fittizio.

Il pacchetto "equivs" può essere usato per [[it/CreateDummyPackage|creare un pacchetto fittizio]] che soddisfi la dipendenza mancante. In questo modo si può mantenere installato il metapacchetto e il gestore dei pacchetti sarà contento. Potrebbe però non valere la pena fare questo lavoro rispetto a semplicemente mantenere installato il pacchetto che si voleva rimuovere.

 4.#4. Chiedere al manutentore del pacchetto di usare una relazione "Recommends:" invece di una "Depends:"

Se si pensa che il pacchetto che si sta cercando di rimuovere dovrebbe essere opzionale, si può chiedere al manutentore di cambiare la relazione "Depends:" in una relazione "Recommends:" segnalando un bug con gravità wishlist. Come al solito, quando si segnala un bug assicurarsi che non sia già stato precedentemente segnalato e considerare inoltre l'ipotesi che il manutentore del pacchetto abbia delle buone ragioni per fare ciò che ha fatto.
Line 349: Line 372:
In teoria sì. I passi necessari dovrebbero essere (da i386 a amd64):

{{{
# dpkg --print-architecture
i386
# dpkg --add-architecture amd64
# dpkg --print-foreign-architectures
amd64
# apt-get update
# apt-get install linux-image-amd64:amd64
# reboot
}}}

Assicurarsi di avere in esecuzione il kernel amd64 prima di procedere con i passi seguenti.

{{{
# apt-get download gcc-4.6-base:amd64 libgcc1:amd64 libc6:amd64 libselinux1:amd64 zlib1g:amd64 libbz2-1.0:amd64 dpkg:amd64
# dpkg -i *.deb
# dpkg --print-architecture
amd64
# dpkg --print-foreign-architectures
i386
}}}

Se si è arrivati fino a qui, si sta di fatto utilizzando un sistema amd64, ma con pacchetti che sono per la maggior parte i386. Si può cercare di sostituirli con i pacchetti amd64 corrispondenti. Se ciò non funziona (non è programmata la conversione di tutte le librerie in Multiarch in Wheezy) rimuovere semplicemente il pacchetto i386 e installare al suo posto la versione amd64.
In teoria sì, vedere [[CrossGrading|Aggiornamenti incrociati]]. Per [[it/Wheezy|Wheezy]] è comunque sempre più sicuro reinstallare.

Translation(s): English - Italiano


Questa pagina è pensata per raccogliere la domande poste spesso sulla mailing list debian-user. I contenuti sono rilasciati nei termini della licenza GPLv2 o, nel caso che una licenza compatibile con le DFSG si applichi a tutto wiki.debian.org, allora nei termini di quella licenza. L'inserimento di materiale in questa pagina comporta l'accettazione di questi termini.

Contents

  1. Perché disturbarsi?
    1. Perché ci si dovrebbe disturbare a scrivere a questa lista? Si vuole chiedere allo sviluppatore/scrivere a debian-devel/segnalare un bug.
  2. Usare Debian
    1. Sarebbe meglio usare Testing/Unstable(Sid) invece di Stable/Testing?
    2. Quanto è pericoloso usare un sistema misto?
    3. Quanto è diversa Ubuntu da Debian?
    4. Il disco rigido, la penna USB o l'unità esterna non ha sempre lo stesso nome di device. Come evitare che ciò accada?
    5. La scheda ethernet si chiama ethX invece di eth0, cosa sta succedendo?
  3. Pacchetti software
    1. Qual è il miglior gestore di pacchetti?
    2. Dov'è il pacchetto pippo?
    3. Il programma pippo cerca (o manca del) file pluto. Dov'è?
    4. Quale pacchetto contiene il file pippo?
    5. Si deve usare upgrade/safe-upgrade o dist-upgrade/full-upgrade per mantenere il sistema aggiornato?
    6. Debian ha Firefox/Cosa è Iceweasel?
    7. Firefox/Iceweasel ha strani problemi (segfault, crash, ...)
    8. Ubuntu/Un'altra distribuzione ha già un kernel/Gnome/KDE/Firefox/... più recnete. Quando lo avrà Debian?
    9. Si è trovato un pacchetto .deb per un software di cui si ha bisogno, è possibile semplicemente installarlo in Debian?
    10. Si sta usando un sistema misto. Come si può sapere quali pacchetti sono da quale distribuzione?
    11. Si è cercato di rimuovere un pacchetto e ora molti altri sono contrassegnati per la rimozione (automatica)
  4. Multiarch
    1. Come si può abilitare il Multiarch
    2. Sono sempre necessari ia32-libs/ia32-libs-gtk ?
    3. Se si cerca di aggiornare ia32-libs/ia32-libs-gtk si ottiene l'installazione di molte librerie i386
    4. Un software non-Debian ha un pacchetto amd64 che dipende da ia32-libs/ia32-libs-gtk, come è possibile disfarsi di ia32-libs/ia32-libs-gtk ?
    5. Ora però APT vuole installare molte librerie i386
    6. Il sistema verrà danneggiato?
    7. Non si desiderano tutte quelle librerie / Si vogliono mantenere i pacchetti omnicomprensivi ia32-libs/ia32-libs-gtk
    8. Sono possibili aggiornamenti incrociati?
    9. Google-earth e il Multiarch
  5. Inviare messaggi in debian-user
    1. Come inviare messaggi/rispondere in debian-user?
    2. Si è posta una domanda seguendo le istruzioni scritte nella domanda "Come inviare messaggi", ma non si è comunque ottenuta risposta
    3. Si deve essere iscritti per inviare messaggi a debian-user?
    4. Oddio! il proprio indirizzo di posta elettonica è disponibile negli archivi della lista e i robot-inviaspam possono ottenerlo. Perché gli indirizzi non vengono mascherati?
    5. Questa lista è piena di spam, fate qualcosa!
    6. Come si possono rimuovere i propri messaggi o indirizzi di posta elettronica dagli archivi?
    7. Ci si è iscritti alla lista e la propria casella di posta è stata inondata da messaggi
    8. Che cos'è il top-posting (e perché non bisognerebbe farlo)?
    9. Perché questa lista non facilita un modo semplice di rispondere alla lista (cioè non modifica il campo reply-to)?
    10. Posso fare una domanda su pincopallo?
    11. Cosa è considerato offtopic per debian-user?
    12. È permesso inviare/allegare grossi file nei messaggi o si deve usare invece un pastebin?
    13. I propri messaggi vengono considerati posta spazzatura e vengono rigettati (o non compaiono mai)
    14. Si invia la posta attraverso server gmail, ma non si ricevono mai i propri messaggi (l'altra posta della lista è a posto)

Perché disturbarsi?

Perché ci si dovrebbe disturbare a scrivere a questa lista? Si vuole chiedere allo sviluppatore/scrivere a debian-devel/segnalare un bug.

Naturalmente si è liberi di farlo. Quasi tutte le liste Debian (inclusa debian-devel) sono aperte e tutti possono inviare messaggi e Debian incoraggia i suoi utenti a segnalare i bug sul Sistema di tracciamento bug di Debian (BTS). MA, considerare prima quanto segue:

  • Essere sicuri al 100% che il problema richieda l'attenzione diretta degli sviluppatori.

Ricordarsi che Debian viene creata da volontari nel loro tempo libero. Distrarli con altri problemi lascerà loro meno tempo per lavorare a cose reali, come la risoluzione dei bag, la pacchettizzazione di nuove versioni del software che tutti aspettano, la pacchettizzazione di software non ancora presente in Debian e il miglioramento o la creazione del software specifico di Debian. Anche se si sa di aver un problema veramente difficile, debian-user è letta da alcune persone molto esperte (inclusi alcuni sviluppatori Debian) che potrebbero avere la soluzione al problema.

  • Alcuni problemi sono causati semplicemente da una configurazione sbagliata.

A volte anche le persone più esperte possono fare cose stupide. Far sì che qualcun altro guardi il proprio problema può essere di aiuto.

  • Assicurarsi che il proprio problema non sia già noto.

Ciò significa che si dovrebbe cercare negli archivi di debian-user (o di altre liste pertinenti) e specialmente nel BTS. È probabile che qualcun altro abbia avuto lo stesso problema (o uno simile) e la soluzione può essere già nota. Anche se si è cercato attentamente, si dovrebbe prima scrivere a debian-user (dicendo cosa si è già provato a fare e cosa si è cercato).

Se, dopo aver considerato tutti i punti descritti sopra, si vuole comunque scrivere a debian-devel, allora assicurarsi che:

  • il problema non sia specifico di un pacchetto (si potrebbe invece segnalare un bug);
  • la cosa non sia già stata discussa (si è cercato negli archivi, vero?);
  • si sta scrivendo alla lista corretta (es. cose legali vanno discusse in debian-legal, cose specifiche del sito web in debian-www, ...)

In caso di dubbi, scrivere in debian-user; a volte le risposte arrivano dopo pochi minuti.

Usare Debian

Sarebbe meglio usare Testing/Unstable(Sid) invece di Stable/Testing?

Questa è una cosa che l'utente e l'amministratore di sistema devono decidere da soli. Se si ha bisogno di alcuni pacchetti più nuovi, provare http://backports.debian.org prima di considerare il passaggio ad un'altra versione. Se si ha Debian su una macchina desktop, testing può essere una buona opzione, ma non raccomandabile per le macchine di produzione. Se si desidera il software più recente che Debian può fornire e non si teme e si può gestire malfunzionamenti, allora si può provare unstable. Se si è in dubbio, usare sempre stable. Ciascuna distribuzione Debian ha i suoi pro e contro; eccone alcuni:

Stable

stable è l'attuale distribuzione Debian GNU/Linux per cui viene fornito il supporto.

  • Viene rilasciata approssimativamente ogni 2 anni.
  • Ha il supporto di sicurezza e risoluzioni di bug occasionali (attraverso l'archivio di sicurezza, stable-updates e i punti di rilascio).
  • È molto stabile, ampiamente testata e raccomandata per gli ambienti dove cambiamenti frequenti non sono desiderabili e sono necessari lunghi tempi di funzionamento ininterrotto.
  • Può avere software un po' vecchiotto e può non avere il supporto per l'hardware molto recente.

    Per maggiori informazioni vedere Debian Stable.

Testing

testing si sta lentamente evolvendo per diventare il prossimo rilascio stabile, ma fino a quel momento è ancora in fase di test. Mano a mano che ci si avvicina al rilascio (congelamento di testing: "freeze") diventa sempre più simile ad un nuovo rilascio stabile (con tutti i pro e i contro).

  • I pacchetti sono già stati un po' testati in unstable.
  • Ha il supporto di sicurezza.
  • Le soluzioni dei bug devono prima passare in unstable (di solito passano 10 giorni, ma ci può volere più tempo). A causa di ciò qualsiasi malfunzionamento necessita di almeno 10 giorni per essere risolto.
  • Richiede un po' di abilità per essere amministrata.

    Per maggiori informazioni vedere Debian Testing.

Unstable - alias Sid, alias Still In Development (ancora in fase di sviluppo), il personaggio di Toy Story che rompeva i giocattoli

unstable contiene pacchetti caricati dagli sviluppatori per il prossimo rilascio, ma non verrà mai realmente rilasciata. I pacchetti invece, se non viene trovato alcun bug critico per il rilascio (e non ci sono problemi di dipendenze), di solito migrano in testing dopo 10 giorni.

  • La maggior parte delle volte ha software piuttosto recente o persino recentissimo.
  • Non c'è alcun supporto di sicurezza simile a ciò che hanno stable o testing, ma i pacchetti aggiornati dovrebbero incorporare anche le risoluzioni ai problemi di sicurezza.
  • I cambiamenti possono avvenire quotidianamente e lo fanno, e questo è il motivo per cui si chiama unstable.
  • Possono verificarsi malfunzionamenti gravi (e lo faranno!); richiede buone abilità per essere amministrata, ma è un buon modo per imparare se non ci si deve preoccupare del tempo di inattività.

    Per maggiori informazioni vedere Debian Sid e Debian Unstable.

Experimental

Questa non è una distribuzione regolare (non si può avere un sistema experimental), ma è citata per completezza.

  • Un posto in cui i manutentori caricano i pacchetti che non sono adatti per unstable, ma che hanno bisogno di un numero più grande di persone che li testino.
  • Non c'è supporto di sicurezza e alcuni pacchetti possono rimanervi per lunghi periodi senza aggiornamenti.
  • Il suo uso non è raccomandato a meno che non si sappia veramente ciò che si sta facendo.

    Per maggiori informazioni vedere Debian Experimental.

Oldstable

Quando viene rilasciata una nuova versione di Debian GNU/Linux l'attuale versione stable diventa oldstable.

  • Ha il supporto di sicurezza per circa un anno dopo il rilascio di stable.

  • Viene raccomandato agli utenti di pianificare un aggiornamento a stable prima che termini il supporto di sicurezza.

    Per maggiori informazioni vedere Debian Oldstable.

Quanto è pericoloso usare un sistema misto?

Dipende da quanti e quali pacchetti si usino, ma può essere più pericoloso dell'uso di una versione unstable pura. L'installazione di pacchetti da rilasci diversi può causare problemi complessi che hanno meno probabilità di verificarsi usando i pacchetti da un unico rilascio. Un esempio è il fatto che pacchetti esistenti possono venire disinstallati a causa di ristrutturazioni interne dei componenti base all'interno del ramo testing o unstable.

Provare prima backports. Se non si riesce a trovare lì ciò che si sta cercando, è anche possibile fare da soli il port di un pacchetto.

Quanto è diversa Ubuntu da Debian?

Ci sono moltissime differenza: alcune grandi, altre piccole, ma tutte possono essere significative.

Principi fondamentali/obiettivi di progettazione

I pacchetti nel ramo principale di Ubuntu sono molto ben curati, molto ben mantenuti e Canonical/Ubuntu fa un ulteriore sforzo per garantire all'utente un'esperienza facile. Ciò ha un prezzo, o più di uno:

Scelta

Mancanza di scelta: si ottiene in modo automatico, ad esempio, un programma di posta invece che la scelta fra diversi. Le scelte vengono fatte per conto dell'utente; è una questione di supporto agli utenti. Debian offre più flessibilità al costo di una maggiore complessità per essere disposta a supportare le scelte degli utenti.

Architetture

Mancanza di architetture: se non si sta usando una macchina Intel/AMD64 o, forse, ARM/Sparc/PPC (a seconda del rilascio), non si può usare Ubuntu. Il fatto che Debian gira su 11 architetture o giù di lì significa che a) il processo è a volte lento b) viene fatto il debug del codice c) il codice viene reso portabile e le risoluzioni vengono fornite a monte.

Rapporto sviluppatori/utenti

Canonical ha un numero relativamente piccolo di sviluppatori pagati, una comunità di volontari altamente motivati, una propugnazione da parte della comunità e un budget per il marketing molto più vasti ed un grande numero di nuovi utenti. Ciò significa che i loro sviluppatori sono enormemente meno numerosi degli utenti e devono essere decise delle priorità. In Ubuntu i pacchetti in universe/multiverse possono pertanto ricevere meno attenzione di quelli in main.

Almeno in teoria, ogni pacchetto in Debian è uguale ed ha un manutentore noto che se ne interessa :) Significa che Debian fa molto del grosso lavoro di pachettizzazione e supporto iniziale per pacchetti di nicchia; significa anche che, se si desiderasse il supporto per R e CRAN per esempio, sarebbe bene andare direttamente in Debian perché il manutentore ha un interesse personale e professionale a far sì che funzioni bene come sistema integrato.

Cicli di rilascio

"Pretendiamo aree di dubbio e incertezza definite rigidamente": Canonical fa questo perché fa un rilascio ogni sei mesi. Questa frequenza costante ha un prezzo: gli utenti si aspettano nuove funzionalità fantastiche ad ogni rilascio e il ciclo di sviluppo è veramente breve. Rilasci con supporto a lungo termine vengono fatti ogni 18 mesi e sono supportati per tre anni sui desktop e cinque su server. È difficile. È molto difficile supportare hardware nuovo con rilasci a lungo termine. I rilasci "normali" possono mescolare pacchetti da Debian stable con testing, unstable o persino experimental (funzionalità fantastiche), ma hanno solamente un breve periodo di test.

Debian "rilascia quando è pronta", ma poi supporta il rilascio fino a circa un anno dopo il rilascio successivo. 22 mesi per rilasciare Etch, 22 mesi per rilasciare Lenny + 12 mesi = 56 mesi. Lento progresso di evoluzione in testing verso il rilascio, punti di aggiornamento minori regolari con risoluzione ai problemi di sicurezza.

Libertà contro pragmatismo

Ubuntu può a volte assumere un atteggiamento pragmatico in favore di "software che funziona" per gli utenti. Ha inoltre la possibilità, che Debian non ha, di fare accordi commerciali per applicazioni di terze parti, ad esempio Oracle/VMWare. [DFSG: non "licenza solo per Debian"]. Canonical trae beneficio dagli ideali di Debian, ma può andare nella direzione opposta :(

Aggiornamenti tra i rilasci

Su questo argomento si sentono molte opinioni diverse. Ubuntu viene generalmente considerata più difficile da aggiornare in modo pulito e potrebbe di fatto esseere più veloce reinstallarla. Di certo non si può saltare un rilascio (la cosa non è neppure supportata) perciò è necessario ad esempio fare i passaggi 8.04, 8.10, 9.04, 9.10. Questa è in parte una conseguenza del breve ciclo di rilascio descritto in precedenza. Nemmeno Debian supporta il salto di un rilascio, ma si ha a disposizione almeno 1 anno per prepararsi all'aggiornamento che sarà per lo più pulito, specialmente se si leggono le Note di rilascio.

Riassunto

Tutto quanto detto fino ad ora è spiegato molto bene in The Official Ubuntu Book e nella recente intervista a Mark Shuttleworth per la rivista "Linux Format". Vale anche la pena di leggere i newsgroup e i forum e planet.debian.org / planet.ubuntu.com per avere una conoscenza migliore delle somiglianze e delle differenze dei due approcci. Debian e Ubuntu hanno entrambe punti di forza: è una simbiosi (a volte difficile), le due condividono molti sviluppatori, ad esempio, ma non necessariamente gli obiettivi finali. Debian però trarrebbe tanto beneficio quanto fa Ubuntu se questa solamente risolvesse il suo maledetto bug n.1 :)

Il disco rigido, la penna USB o l'unità esterna non ha sempre lo stesso nome di device. Come evitare che ciò accada?

Non lo si può prevenire; ciò avviene per il modo in cui il kernel fa la rilevazione dell'hardware, ma ci sono diversi modi per evitare che sia un problema. Sembra che il metodo più semplice sia di usare etichette invece dei numeri di device. Fondamentalmente in fstab si deve sostituire /dev/sda1 (o hda2 o qualsiasi altra cosa) con LABEL=miaetichetta. Se si hanno anche problemi di avvio (poiché la partizione / viene assegnata ad un diverso nome di device) sarà necessario modificare anche /boot/grub/menu.lst. Non modificare la sezione effettivamente usata perché i cambiamenti verranno persi al prossimo aggiornamento del kernel. Trovare invece la riga

# kopt=root=/dev/hda1

e sostituirla con

# kopt=root=LABEL=mia_etichetta_root

Una volta finito si deve eseguire update-grub da root.

Un'alternativa all'uso delle etichette è l'uso degli UUID. Si può scoprire l'UUID di un device con blkid(8).

A partire da Squeeze tutte le nuove installazioni hanno il file /etc/fstab che contiene UUID e anche grub2 li gestisce in modo corretto.

La scheda ethernet si chiama ethX invece di eth0, cosa sta succedendo?

Udev sta assegnando lo stesso nome di device ad una scheda (in base al suo MAC), anche se sono state rimosse tutte le altre schede nel sistema. Se non si desidera che ciò accada, si può:

  • rimuovere il file /etc/udev/rules.d/70-persistent-net.rules. Verrà ricreato al successivo avvio con la numerazione nell'ordine in cui il kernel vede i dispositivi.

  • modificare il file /etc/udev/rules.d/70-persistent-net.rules. Questo è raccomandato se sia ha più di una scheda, dato che lasciare che udev rigeneri il file non garantisce un ordine particolare.

Pacchetti software

Debian è noto per il suo sistema di pacchetti robusto, vasto e facile da usare. Le operazioni relative alla gestione dei pacchetti che possono essere fatte sono sofisticate, facilmente inseribili in script e rendono l'uso di Debian un'esperienza relativamente semplice e a prova d'errore. Le domande che seguono trattano tutte di aspetti relativi alla gestione dei pacchetti.

Qual è il miglior gestore di pacchetti?

Sebbene stabilire "il migliore" gestore di pacchetti è una questione di opinioni personali, il progetto Debian e molti sviluppatori ed utenti Debian raccomandano aptitude. Per ulteriori dettagli vedere qui.

Dov'è il pacchetto pippo?

Esiste una varietà di strumenti che possono rispondere a questa domanda veramente frequente: apt-cache search pippo pluto restituisce tutti i pacchetti con sia pippo sia pluto nel nome o nella descrizione; aptitude search pippo restituisce tutti i pacchetti con pippo nel nome di pacchetto. Questi sono solo due modi tra molti. Leggere man apt-cache o man aptitude a seconda dello strumento scelto. Da ultimo, http://packages.debian.org ha anche un comodo motore di ricerca e non ci si dimentichi dell'amico http://www.google.com.

Il programma pippo cerca (o manca del) file pluto. Dov'è?

Questo è facile: apt-file update && apt-file search pluto. Usare grep come necessario. man apt-file.

Quale pacchetto contiene il file pippo?

Vedere la domanda precedente. Se il file è già nel sistema dpkg dovrebbe saperlo (e di solito è più veloce come metodo)

$ dpkg -S /percorso/di/pippo

Notare che i file in /home/, /usr/local/ e alcuni altri posti non sono sotto il controllo del gestore dei pacchetti. Vedere lo standard FSHS per la gerarchia del file system (disponibile anche come pagina man hier(7) ) per una spiegazione di come sono organizzati i file nel sistema.

Si deve usare upgrade/safe-upgrade o dist-upgrade/full-upgrade per mantenere il sistema aggiornato?

Può essere d'aiuto capire cosa fa ciascun comando:

  • apt-get upgrade: aggiorna tutti i pacchetti, senza installare o rimuovere pacchetti, anche se ciò significa che alcuni pacchetti non vengono aggiornati.

  • aptitude safe-upgrade: aggiorna tutti i pacchetti, installandone di nuovi se necessario, ma senza rimuoverne, anche se ciò significa che alcuni pacchetti non vengono aggiornati.

  • aptitude full-upgrade / apt-get dist-upgrade: aggiornano tutti i pacchetti e, se necessario, ne installano di nuovi o ne rimuovono di installati.

Naturalmente tutte queste azioni chiederanno conferma all'utente, perciò è una buona idea controllare le azioni proposte prima di procedere ;).

In pratica quanto detto significa che eseguire apt-get upgrade o `aptitude safe-upgrade potrebbe essere sufficiente a mantenere il sistema aggiornato, a seconda che si usi stable, testing o unstable (o un sistema misto). Per questo motivo è generalmente raccomandato di non usare apt-get dist-ugprade o aptitude full-upgrade` a meno che non sia realmente necessario (pacchetti che non vengono aggiornati perché è necessario installarne o rimuoverne degli altri).

Notare che aptitude nella modalità visuale non ha un'equivalente di `aptitude safe-upgrade` e premendo Maiusc-u si prepara sempre l'equivalente di aptitude full-upgrade. Ciò perché nella schermata dell'anteprima si ha comunque la possibilità di controllare e modificare le singole azioni a seconda delle necessità.

Debian ha Firefox/Cosa è Iceweasel?

Si dovrebbe in verità leggere Dov'è il pacchetto pippo? più sopra, comunque Debian fornisce Iceweasel, un Firefox rimarchiato.

Firefox/Iceweasel ha strani problemi (segfault, crash, ...)

Prima provare disabilitando tutte le estensioni eseguendo

$ iceweasel -safe-mode

e vedere se in questo modo si risolve il problema. Un'altra cosa che si può provare è di rimuovere o spostare la propria directory .mozilla o di creare un nuovo account utente.

Ubuntu/Un'altra distribuzione ha già un kernel/Gnome/KDE/Firefox/... più recnete. Quando lo avrà Debian?

Risposta breve: molto probabilmente con il prossimo rilascio. Vedere sopra per una spiegazione veloce sul funzionamento dei rilasci Debian.

Risposta lunga: i Debian Developer fanno del loro meglio per pacchettizzare il software rilasciato a monte non appena lo considerano abbastanza stabile da essere incluso in Debian, perciò il pacchetto cercato potrebbe già essere disponibile in testing, unstable o experimental. A meno che testing non sia nello stato congelato freeze (simile a „Candidata al rilascio”) il nuovo software migra appena possibile da unstable a testing (che diventerà poi stable al prossimo rilascio), ma non verrà mai incluso nel rilascio stabile attuale, perché per definizione il rilascio non deve essere modificato (a parte per le risoluzioni dei problemi di sicurezza e di alcuni bug gravi).

Se si vuole comunque restare fedeli a stable (invece di testing o unstable) l'opzione migliore è cercare in http://backports.debian.org il pacchetto di cui si ha bisogno.

Si può pensare che Debian sbagli e che dovrebbe adottare la politica di rilascio di qualche altra distribuzionen, ma questo sistema ha dimostrato tutto il suo valore nel corso di molti anni e dà agli utenti moltissime scelte. Nel tempo sono state proposte varie alternative, ma tutte hanno qualche svantaggio rispetto allo schema attuale. Cercare negli archivi (anche quelli delle liste debian-devel e debian-project) prima di iniziare una nuova discussione a questo proposito.

Si è trovato un pacchetto .deb per un software di cui si ha bisogno, è possibile semplicemente installarlo in Debian?

Dipende. Se il pacchetto è stato creato specificatamente per Debian (quale versione?) potrebbe funzionare, ma se non lo fa non ci si può aspettare alcun supporto da Debian. Se il pacchetto è stato creato per Ubuntu o qualche altra distribuzione derivata le probabilità che funzioni sono molto minori. Si può provare a ricompilarlo in Debian (se sono disponibili anche i sorgenti).

Si sta usando un sistema misto. Come si può sapere quali pacchetti sono da quale distribuzione?

Se si è in questa situazione significa che si prova piacere a giocare col fuoco, ma poi non si sa rispondere a questa semplice domanda. E detto questo, basta prediche. :) Provare apt-show-versions.

Si è cercato di rimuovere un pacchetto e ora molti altri sono contrassegnati per la rimozione (automatica)

Questo solitamente avviene perché si sta tentando di rimuovere un pacchetto che è una dipendenza di un metapacchetto. In una situazione simile tutti i gestori di pacchetti cercano di rimuovere anche il metapacchetto ma, come conseguenza, tutte le dipendenze del metapacchetto vengono quindi considerate non utilizzate e vengono contrassegnate per la rimozione (automatica). Ci sono vari modi di risolvere un problema simile:

  • 1.#1. Contrassegnare le altre dipendenze come installate manualmente e lasciare che il gestore dei pacchetti rimuova il metapacchetto.

Questo manterrà installati gli altri pacchetti, ma ha il difetto che le nuove dipendenze del metapacchetto non verranno installate. Questo non è un problema per stable, ma solo per testing, unstable o per gli aggiornamenti ad un nuovo rilascio.

  • 2.#2. Forzare il gestore dei pacchetti ad ignorare la dipendenza mancante e mantenere installato il metapacchetto.

Questo è pericoloso, a meno di non sapere esattamente ciò che si sta facendo e il gestore dei pacchetti continuerà a lamentarsi dei pacchetti difettosi. Vedere il prossimo punto per una soluzione migliore.

  • 3.#3. Usaree "equivs" per creare un pacchetto fittizio.

Il pacchetto "equivs" può essere usato per ?creare un pacchetto fittizio che soddisfi la dipendenza mancante. In questo modo si può mantenere installato il metapacchetto e il gestore dei pacchetti sarà contento. Potrebbe però non valere la pena fare questo lavoro rispetto a semplicemente mantenere installato il pacchetto che si voleva rimuovere.

  • 4.#4. Chiedere al manutentore del pacchetto di usare una relazione "Recommends:" invece di una "Depends:"

Se si pensa che il pacchetto che si sta cercando di rimuovere dovrebbe essere opzionale, si può chiedere al manutentore di cambiare la relazione "Depends:" in una relazione "Recommends:" segnalando un bug con gravità wishlist. Come al solito, quando si segnala un bug assicurarsi che non sia già stato precedentemente segnalato e considerare inoltre l'ipotesi che il manutentore del pacchetto abbia delle buone ragioni per fare ciò che ha fatto.

Multiarch

A partire da Debian 7.0 (wheezy) è possibile installare pacchetti da architetture diverse sullo stesso sistema; l'uso più comune è l'installazione di pacchetti i386 su amd64 (o viceversa).

Vedere Multiarch per maggiori informazioni.

Come si può abilitare il Multiarch

Non appena sono stati installati APT e dpkg da wheezy, per attivare il supporto multi-architettura si può fare quanto segue (supponendo un sistema amd64 che necessiti di pacchetti i386):

# dpkg --add-architecture i386
# apt-get update

Sono sempre necessari ia32-libs/ia32-libs-gtk ?

Probabilmente no, vedere in seguito.

Se si cerca di aggiornare ia32-libs/ia32-libs-gtk si ottiene l'installazione di molte librerie i386

Questo è normale. ia32-libs/ia32-libs-gtk prima contenevano tutte quelle librerie. Per poter assicurare le stesse funzionalità ora dipendono invece dai corrispondenti pacchetti i386. Potrebbe essere possibile eliminarne qualcuno, vedere in seguito.

Un software non-Debian ha un pacchetto amd64 che dipende da ia32-libs/ia32-libs-gtk, come è possibile disfarsi di ia32-libs/ia32-libs-gtk ?

Se un pacchetto amd64 dipenda da ia32-libs/ia32-libs-gtk, è di fatto un software a 32 bit è il produttore avrà probabilmente anche un pacchetto i386. Attivare il Multiarch, installare il pacchetto i386 invece di quello amd64 e lasciare che sia APT a gestire le dipendenze.

Ora però APT vuole installare molte librerie i386

Sì, questo è il comportamento normale ma, a meno che il pacchetto non abbia moltissime dipendenze, le librerie dovrebbero comunque essere meno di quelle contenute nei vecchi (omnicomprensivi) pacchetti ia32-libs/ia32-libs-gtk, o delle librerie da cui dipendono ia32-libs/ia32-libs-gtk.

Il sistema verrà danneggiato?

Probabilmente no, ma se si vuole andare sul sicuro non aggiornare a Wheeze prima del suo rilascio.

Non si desiderano tutte quelle librerie / Si vogliono mantenere i pacchetti omnicomprensivi ia32-libs/ia32-libs-gtk

Per questo è necessario rimanere con Squeeze.

Sono possibili aggiornamenti incrociati?

In teoria sì, vedere Aggiornamenti incrociati. Per Wheezy è comunque sempre più sicuro reinstallare.

Google-earth e il Multiarch

Alla data del 18 dicembre 2012 è impossibile installare Google-earth con il Multiarch a causa di binari i386 mancanti, e il Multiarch permette solo la co-installazione di librerie.

Inviare messaggi in debian-user

Come inviare messaggi/rispondere in debian-user?

Vedere le regole di comportamento delle mailing list Debian. È anche utile porre le proprie domande in maniera intelligente e se si risponde citando in maniera corretta.

Si è posta una domanda seguendo le istruzioni scritte nella domanda "Come inviare messaggi", ma non si è comunque ottenuta risposta

Sembra che non si abbia veramente letto questa FAQ a cui faceva riferimento la risposta precedente. (La risposta a questa domanda è in quella FAQ, l'autore di questa pagina ha controllato:) ).

Si deve essere iscritti per inviare messaggi a debian-user?

La politica di Debian è di avere mailing list aperte. Ciò significa che la maggior parte delle liste permettono a tutti di scrivere liberamente (la posta spazzatura occasionale che ne risulta è inevitabile, ma è solo un inconveniente di poco conto: la lista ha filtri eccellenti). Gli iscritti alla lista, tuttavia, non possono indovinare se si è iscritti o meno, perciò si dovrebbe richiedere di inviare le risposte anche in CC al proprio indirizzo (o impostare il campo Reply-To in modo appropriato).

Oddio! il proprio indirizzo di posta elettonica è disponibile negli archivi della lista e i robot-inviaspam possono ottenerlo. Perché gli indirizzi non vengono mascherati?

Quel tipo di rimedio non aiuta veramente a combattere la posta spazzatura, ma solo un suo sintomo. Per una spiegazione più dettagliata vedere http://www.interhack.net/pubs/munging-harmful.

Questa lista è piena di spam, fate qualcosa!

A dire il vero non lo è; per ogni messaggio di spam che riesce a passare i filtri ce ne sono molte migliaia che sono bloccate. Inoltre i filtri sono regolati in modo da evitare qualsiasi falso positivo. Se si desidera aiutare (o almeno non si vogliono peggiorare le cose):

  • NON rispondere allo spam, mai! (rispondere rende difficile o persino impossibile rimuovere lo spam dagli archivi dato che diventa parte di un thread legittimo)

  • NOT citare lo spam, nemmeno in modo parziale (ciò confonde i filtri)
  • SEGNALARE lo spam solamente inoltrandolo a report-listspam@lists.debian.org

Come si possono rimuovere i propri messaggi o indirizzi di posta elettronica dagli archivi?

Risposta breve: non si può. Anche se gli amministratori degli archivi lo facessero per gli archivi ufficiale Debian, questa lista è disponibile in diversi altri luoghi (gmane, googlegroups, ...) sui quali il progetto Debian non ha alcun controllo. Vedere anche la politica ufficiale per ulteriori informazioni. more info.

Ci si è iscritti alla lista e la propria casella di posta è stata inondata da messaggi

La mailing list debian-user è una lista con un volume di traffico molto alto, ci si dovrebbe aspettare di ricevere circa 150 messaggi al giorno, ma ci sono modi per gestire la cosa:

  • impostare un filtro che sposti tutta la posta della lista in una cartella dedicata (se si desidera tutta la posta) o persino per cancellare tutta la posta della lista tranne filoni di discussione specifici (ad esempio quelli a cui si ha dato inizio)
  • usare alternative:
    • gmane è un gateway da-posta-a-news con una interfaccia web alternativa carina (richiesta iscrizione?)
    • anche googlegroups ha debian-user in caso si preferisca la sua interfaccia (necessaria iscrizione)
    • debian-user è disponibile anche come newsgroup (direttamente o via gmane)
    • leggere gli archivi (ma fare attenzione al fatto che può volerci un po' più di tempo prima che un messaggio appaia negli archivi)
  • semplicemente disiscriversi. Se si deseidera solamente riceverele risposte ai propri messaggi, si può chiedere di essere messi in CC (o impostare il campo Reply-To in modo appropriato)

  • usare un client di posta decente. Dovrebbe supportare almeno un qualche modo di raggruppare i messaggi per discussione (e di ordinarli se non viene fatto con altri metodi) e di rispondere-alla-lista (se si ha in progetto di partecipare alle discussioni).

Che cos'è il top-posting (e perché non bisognerebbe farlo)?

Ad entrambe le domande si può rispondere con questo esempio (visto in una firma):

R: Perché disturba il modo in cui si legge

Q: Perché il top-posting è male?

A: Scrivere la propria risposta prima della domanda

Q: Che cos'è il top-posting?

Perché questa lista non facilita un modo semplice di rispondere alla lista (cioè non modifica il campo reply-to)?

Risposta breve: di nuovo, è lo standard. Per una spiegazione esaustiva vedere questo documento. In caso il proprio programma di posta non supporti le risposte alla lista allora usare l'opzione Rispondi a tutti e cancellare tutti gli indirizzi tranne quello della lista.

Posso fare una domanda su pincopallo?

Non chiedere se si può chiedere, porre direttamente la propria domanda, ma guardare anche la domanda sui messaggi offtopic.

Cosa è considerato offtopic per debian-user?

Generalmente tutto ciò che non ha una relazione con Debian è considerato offtopic (fuori argomento) su debian-user. Se si vuole proprio, assolutamente inviare un messaggio di questo tipo:

  • considerare l'invio invece alla lista offtopic

  • indicare [OT] nell'oggetto del messaggio così che gli iscritti non interessati possano ignorarlo

  • tenere a mente che alcuni iscritti leggono la lista usando connessioni molto lente o poco affidabili e anche alcuni kilobyte fanno la differenza

Chiedere domande relative a qualsiasi software pacchettizzato per Debian è solitamente ok, specialmente se non si riesce a dire se il problema è specifico di Debian o no (ma indicarlo).

Chiedere domande generali sull'uso di un qualsiasi software è solitamente scoraggiato dato che la maggior parte dei progetti ha delle proprie liste di discussione dedicate.

È naturalmente accettabile discutere configurazioni/personalizzazioni specifiche per Debian (si è letto prima il file /usr/share/doc/<pacchetto>/README.Debian?) o chiedere aiuto con una versione che è disponibile in un rilascio Debian attuale ma che non è più supportato dagli autori originali a monte.

È permesso inviare/allegare grossi file nei messaggi o si deve usare invece un pastebin?

Molti iscritti ricevono i messaggi della lista attraverso connessioni lente, costose o poco affidabili. D'altro canto non è certo che i messaggi arrivino in un ordine specifico (basti pensare alle liste grigie).

Se possibile fare sempre in modo che il proprio messaggio sia autonomo (considerare gli utenti che leggono da scollegati e che si connettono solo per inviare e ricevere i messaggi).

L'output generato dal computer lungo alcune decine di righe dovrebbe sempre essere incluso o allegato (fare attenzione a non mandare le righe a capo). I file di log (o l'output di dmesg) vanno anch'essi bene nella maggior parte dei casi, ma cercare di includere solo le parti rilevanti. I documenti o le immagini (istantanee) non dovrebbero mai essere inviate e verrebbero in ogni caso probabilmente scartati dal server della lista.

I propri messaggi vengono considerati posta spazzatura e vengono rigettati (o non compaiono mai)

Provare ad iscriversi alla lista bianca. Vedere anche questa domanda nel caso si inviino i messaggi da un account gmail.

Si invia la posta attraverso server gmail, ma non si ricevono mai i propri messaggi (l'altra posta della lista è a posto)

Gmail ha un'opinione un po' particolare di come dovrebbe funzionare un server di posta. Dato che c'è già una copia del messaggio nella cartella Inviata, la copia in entrata dalla mailing-list viene scartata in modo silenziosa. Ma se qualcun altro risponde al messaggio inviato allora questo nuovo messaggio apparirà nella casella in entrata e in questo modo ci richiamerà anche il messaggio originale perché è una risposta ad esso. Il risultato? Non si vedono i propri messaggi reinviati da una mailing-list a meno che qualcun altro non risponda alla discussione.

Se si vuole comunque usare Gmail per inviare posta alla lista, ecco alcuni possibili modi di aggirare il problema:

  • tenere semplicemente a mente che i propri messaggi inviato saranno nella cartella Inviata fino a che qualcuno non risponde.
  • configurare il proprio programma di posta in modo che salvi la posta in uscita nella stessa cartella. La maggior parte (tutti?) dei programmi di posta dovrebbe essere in grado di farlo in base alla cartella.
  • usare un diverso account per ricevere la posta della lista. La maggior parte delle liste Debian (inclusa debian-user) sono aperte e tutti vi possono scrivere, perciò non è necessario essere iscritti per poter inviare messaggi (si può comunque iscriversi alla lista bianca) per aiutare i filtri anti-spam di tutte le liste a sapere che i propri messaggi non sono spam.).

Sembra che Gmail consideri questa una funzionalità e non abbia intenzione di modificarla, sebbene ciò sia richiesto da molti utenti. Si può provare a scrivere a Gmail riguardo a questo, forse alla fine ascolteranno gli utenti.


FAQ