Gestioni dei pacchetti software

WIKI antiX MX Linux - La gestione del Software

Indice

Premessa.
Gestione dei Pacchetti con Linux.
Tipologia dei pacchetti.
Gestori/installatori di pacchetti presenti nei repository.
Synaptic.
Installazione di pacchetti con Synaptic.
Rimozione dei pacchetti.
Aggiornamento dei pacchetti.
I Repository.
Altri sistemi per la gestione dei pacchetti Debian.
APT.
Gestori/installatori di pacchetti presenti localmente nel filesystem.
Schema riassuntivo installazione tipologie di software.
Pacchetti .deb.
Pacchetti .rpm.
File .tar.gz e .tar.bz2.
File .sh .run .bin .package .py.
DPKG Installazione di pacchetti .deb con Dpkg.
GDEBI Installazione di pacchetti .deb con Gdebi.
ALIEN Convertire e installare i pacchetti RPM.
SORGENTI Compilare e installare sorgenti.

Premessa

Questo documento è stato redatto considerando di poter essere facilmente compreso da utenti che si sono avvicinati da poco al sistema operativo Gnu/Linux e quindi ne abbiano ancora una scarsa conoscenza.

I comandi da digitare al terminale verranno preceduti dal simbolo: $ 
Questo simbolo non andrà digitato, serve ad indicare che il comando che segue è stato richiesto in qualità di utente normale.

Alcuni comandi molto potenti, per essere eseguiti dal sistema operativo, devono essere richiesti dall'amministratore del sistema (root), il simbolo che comparirà in questo caso sarà #. 

Per essere riconosciuti come amministratori dal sistema è necessario scrivere sul terminale il comando su dopodichè va digitato il tasto invio, scrivendo subito dopo la password dell'amministratore (password di root).

Il simbolo del cancelletto # in contesti diversi può avere tutto un altro significato. Quando è presente in una riga di un file di sistema, rende non leggibile al sistema la parte di riga che segue il cancelletto, serve quindi per disabilitare una funzione, un opzione, la voce di un elenco, ecc. Si potrà facilmente ripristinare la situazione precedente semplicemente eliminando il cancelletto dalla riga. Può anche servire a inserire delle spiegazioni, degli aiuti a chi si accinge a leggere e modificare il file, senza che il sistema prenda in considerazione quelle righe destinate non a lui ma all'utente amministratore. 

 

Gestione dei Pacchetti con Linux

Se sei abituato a Microsoft Windows, probabilmente hai poca familiarità con il concetto di “pacchetto”. Infatti la gestione del software è uno dei peggiori difetti in Microsoft Windows, ed è una delle ragioni per cui è così vulnerabile e instabile.
Se installi Windows su un computer, ti accorgerai che non vengono installati molti programmi. Ci sono molti file che non potrai leggere, molti siti web in cui non potrai visionare, o scaricare, contenuti multimediali e molte operazioni basilari che non sarai in grado di fare, se non ti procuri o acquisti un gran numero di applicativi supplementari.
Ti trovi costretto a passare da un sito web all'altro per cercare di scaricare un programma per decomprimere i file, una suite di programmi per l'ufficio, un antivirus, eccetera eccetera. Inoltre non sai mai se puoi fidarti della società produttrice del software che installi.
Certamente puoi fidarti di Mozilla, OpenOffice, IBM e altre società famose, ma puoi fidarti di alcune ditte che vendono ad esempio prodotti shareware, o addirittura che propongono antivirus?
Un altro problema riguarda la gestione del software, infatti Windows non lo controlla. È il software stesso che decide come si deve aggiornare, o se deve farlo. Tu non hai modo di tenere aggiornato il software.
Le distribuzioni Linux solitamente mantengono aggiornato tutto il software di cui hai bisogno, e garantiscono che sia stato testato e pacchettizzato per la tua versione e la tua distribuzione.
Così, ad esempio, quando installi con MX Linux i programmi Opera, Real Player o Google Earth, queste applicazioni non vengono da Opera, Real o Google. Naturalmente il download avviene dai loro siti web, ma sono resi disponibili solo dopo essere stati pacchettizzati e controllati. In altre parole, non sei obbligato a navigare in Internet per cercare il software che ti serve: ogni cosa di cui hai bisogno è già stata testata per te e per il tuo sistema, e ciò che devi fare è solo installare il pacchetto giusto.
AntiX e MX Linux può essere aggiornato facilmente attraverso il programma di gestione dei pacchetti “Synaptic”, che non soltanto manterrà aggiornato il sistema operativo, ma anche il software aggiuntivo installato sul tuo computer.
Un ulteriore problema di Windows è che la maggior parte del software è monolitico. Molte applicazioni vengono distribuite sotto forma di enormi file eseguibili o archivi che non contengono solo i programmi necessari, ma anche tutte le librerie di cui hanno bisogno.
La gestione dei pacchetti in Linux e in tutti i moderni sistemi operativi è radicalmente diversa.
I pacchetti sono parti di software che possono dipendere le une dalle altre e questo permette di ridurre la dimensione dei programmi. Infatti, per fare un esempio, se due applicativi utilizzano le stesse librerie è inutile che ciascuno se le porti dietro, con il risultato che la stessa libreria sarà presente nel nostro disco fisso magari 10 volte, basterà installare solo il “cuore” del programma e poi appoggiarsi al software già presente o installare solo quello che serve. Questo è il motivo per cui, sul mio computer, per avere un numero di applicativi simile (addirittura un pò inferiore) a Gnu/Linux, nella partizione di Vista viene occupato 4 volte più spazio: 11 giga contro i 3 di MX, a parità (circa) di software aggiuntivo installato.
Questa filosofia a moduli permette di installare sistemi operativi Linux moderni su macchine vecchie o con prestazioni limitate. Questo, a essere sinceri, può avere un suo rovescio della medaglia, perchè il software presente in un sistema Linux, essendo così interconnesso, dovrà avere una coerenza complessiva degli aggiornamenti. Questa coerenza viene garantita dal semplice, ma efficace, programma di gestione del software: Synaptic (o meglio da Apt che ne costituisce “il motore”).
Un certo pericolo di instabilità ci può essere se viene utilizzato software in forma di codice sorgente, ma si tratta di una pratica che dovrebbe essere attuata solo da utenti un pò esperti che sanno adottare le giuste precauzioni per evitare problemi. Un principiante può tranquillamente accontentarsi dei più di 45.000 pacchetti software gestiti da Synaptic.

Windows non ha il problema dell'eventuale instabilità dei sorgenti semplicemente perchè non è possibile installarli, ma ha grossi problemi di instabilità che tutti conosciamo, tanto per fare un esempio: i virus.

Tipologia dei pacchetti

I formati dei pacchetti più utilizzati attualmente sono RPM, DEB, TGZ e BZ2.

Il formato RPM (RedHat Package Manager), è stato creato dalla RedHat per agevolare la gestione del software della propria distribuzione ma, visto il successo del sistema, è stato adottato anche da altre distribuzioni (Mandriva, Suse, Turbolinux, ecc.).
RPM è in grado di verificare la presenza di tutto il software necessario al funzionamento del pacchetto (le dipendenze), impedendone l’installazione se non tutto è a posto. In questo modo l’installazione e la rimozione di software risultano semplificate e si evita di causare malfunzionamenti durante l’installazione.

Il formato DEB è stato sviluppato dalla distribuzione Debian e dalle distribuzioni che hanno scelto di avvalersi di questo sistema come antiX e MX Linux.
Il formato Deb, pur partendo dagli stessi presupposti di RPM, ha un controllo delle dipendenze migliore e, accoppiato con programmi quali Apt, permette di scaricare automaticamente le dipendenze richieste, o addirittura aggiornare al volo un’intera distribuzione.

TGZ (o TAR.GZ) è un formato molto diffuso nella comunità Linux e più in generale UNIX. Esso si basa sulla combinazione di due comandi per l’ archiviazione (tar) e la compressione dei file (gzip e gunzip).
Ci sono però dei problemi con questo formato (almeno per i meno esperti), infatti non effettua controlli sulle dipendenze e non si sa con certezza cosa contiene: potrebbe essere composto da file binari (e quindi immediatamente eseguibile) oppure di soli file sorgenti.

Il formato BZ2 è simile a TGZ, ma utilizza un algoritmo più efficiente (e lento).

Gestori/installatori di pacchetti presenti nei repository

Synaptic

 

Synaptic è un tool grafico che permette di installare, rimuovere, aggiornare ed ottenere informazioni sui pacchetti software disponibili negli archivi (repository) on-line, previsti per la distribuzione in uso.
E' un frontend (un'interfaccia grafica) semplice ed intuitivo di APT, il sistema di gestione dei pacchetti di tipo .deb. 
Ci sono anche altri modi per scaricare e installare pacchetti .deb, che prenderemo in esame nei capitoli successivi. 
Synaptic può essere lanciato, in MX Linux, da MenuStart -> Sistema -> Gestore pacchetti, o puoi semplicemente cliccare sull'icona a forma di scatolina gialla nella barra del panello. In antiX si andrà in Centro di Controllo, scegliere la linguetta Sistema e cliccare il pulsante "Gestisci pacchetti software".
Sarà necessario fornire la password di root per installare o rimuovere il software, e naturalmente, se desideri utilizzare i repository (detti anche repo) on-line, avrai bisogno di essere collegato a internet. Non disponendo della rete si potrà utilizzare questo programma appoggiandosi a Dvd, contenenti i pacchetti che ci interessano, da inserire nel lettore del pc. Questa opzione verrà descritta in un capitolo a parte. 
L'uso di Synaptic per installare, rimuovere o aggiornare “programmi” e utility varie è di una semplicità disarmante.

Immaginiamo di voler installare l'editor audio “Audacity”.
Sappiamo che questo programma, essendo piuttosto complesso, non è composto solo dal pacchetto principale, avente appunto il nome “audacity”. Vi saranno anche librerie e pacchetti di supporto, cioè in sostanza le dipendenze, ed inoltre potrebbe essere importante qualche plugin aggiuntivo. Ebbene, con Synaptic installare i pacchetti che servono, di un programma per noi ancora sconosciuto, non è minimamente un problema.

Basterà cliccare sull'icona “Cerca” e, sulla finestrella pop-up che compare, scrivere “audacity”.
Nella lista di pacchetti che si genera nell'area sotto a “Cerca”, cliccare col destro sul nome del pacchetto “audacity” e selezionare “installa”, poi cliccare sull'icona “Applica”, posta vicino a “Cerca”. Synaptic si arrangia ad installare il pacchetto e tutte le dipendenze necessarie, ad esempio il pacchetto audacity-data e diversi altri.
Noi abbiamo solo il compito di avviare l'installazione del pacchetto principale cioè quello con lo stesso nome del programma, dopo di che rimane una sola cosa da fare: cliccare sull'icona “Proprietà” di fianco a “Cerca”.

Nella scheda “Dipendenze” in “Proprietà” posso vedere se ci sono pacchetti “consigliati” e “raccomandati”.
Questi costituiscono del software aggiuntivo che ampliano le funzioni del software principale, come i “plugin”. Se voglio un programma più completo li cercherò con la funzione cerca, ne leggerò la descrizione e deciderò se, e quali, installare.
Tutto qui.

Se voglio aggiornare i pacchetti, clicco sul pulsante “Stato” nell'area in basso a destra della finestra principale, poi nell'area sopra “installato aggiornabile”, quindi mi comparirà una lista di pacchetti con un punto esclamativo sul quadratino, di fianco al nome, che si presenterà grigio e potrò aggiornarli tutti cliccando sull'icona “Seleziona aggiornamenti”, in alto di fianco ad “Aggiorna”. Se invece di aggiornarli tutti, lo voglio fare solo per qualcuno, ci clicco sopra col destro e nel menù a discesa che compare invece di scegliere “installa” o “rimuovi” scelgo “aggiorna”.
Questo, in soldoni, è ciò che è necessario sapere per installare, aggiornare o rimuovere applicativi, tuttavia Synaptic ci dà molte possibilità in più nella gestione del software, perciò vale la pena di conoscerne in maniera più approfondita le varie funzioni a disposizione. Cosa che ci apprestiamo a fare.

Analizziamo le diverse aree della finestra principale, seguendo i numeri presenti nell'immagine.

1 Barra delle Funzioni - Dove si trovano i pulsanti:

 


 “Aggiorna” , anche detto “update”, che permette di aggiornare l'elenco dei pacchetti disponibili nei repositori e le informazioni relative a ciascun pacchetto. E' una funzione che va avviata ogni qualvolta si attiva o si disattiva un nuovo “repo”, per aggiornare correttamente l'elenco pacchetti, ma male non fa premerlo periodicamente in ogni caso nel caso non vi fosse stata una corretta trasmissione di informazioni.

“Seleziona aggiornamenti” permette di procedere, con un solo comando, all'aggiornamento di tutti i pacchetti aggiornabili tra quelli che abbiamo installato. In pratica è come se andassimo a selezionare la voce “installato aggiornabile”, presente nell' “Area delle Categorie” (dopo aver selezionato “Stato” nell'area n°2), e poi nei pacchetti che si presenterebbero a destra, nell' “Area dei Pacchetti”, cliccassimo col destro su ognuno di essi in maniera da far comparire un menù a discesa su cui scegliere “aggiorna”. Se i pacchetti interessati sono tanti, selezionare “aggiorna” per ognuno può essere poco pratico.

Attenzione però nell'aggiornare sempre tutto in maniera troppo automatica.

Alcuni pacchetti potrebbero perdere configurazioni importanti per noi, che potremmo aver impostato con un intervento manuale nei files sistema. Casi rari, ma di cui è meglio ricordarsene.

Va detto che di norma il sistema prima di sovrascrivere questo tipo di files ci chiede se vogliamo usare la configurazione modificata o quella del manutentore del pacchetto ma un principiante spesso non sa di che cosa si stia parlando e potrebbe rispondere a caso.

Ad ogni modo conviene in genere controllare quello che si fa evitando troppi automatismi.

Può essere pratico, ottenere l'elenco dei pacchetti “installato aggiornabile”, poi cliccare “seleziona aggiornamenti” ed eventualmente deselezionare quei rari pacchetti che non vogliamo aggiornare.

“Applica”. dobbiamo cliccare su questo pulsante quando, dopo aver selezionato un pacchetto, cliccandoci col destro, decidiamo se installarlo, disinstallarlo o aggiornarlo. Potremo quindi selezionare l'installazione di diversi pacchetti, e solo alla fine dare “applica” in modo che vengano installati tutti in un colpo solo. L'installazione (o la rimozione o altro) non partirà immediatamente ma ci verrà chiesta ulteriore conferma attraverso una finestra “pop-up” che ci informerà di quanto spazio andiamo ad occupare con i nostri nuovi programmi o se ci sono incompatibilità tra pacchetti. Leggiamo con attenzioni questi avvisi prima di dare “OK”
 

“Proprietà” questo pulsante ci dà informazioni importanti sul pacchetto che stiamo per installare.

Vediamole velocemente.

In “Descrizione” viene spiegato a cosa serve il pacchetto-programma selezionato. Se si tratta di un pacchetto di supporto, prima viene descritta l'attività dell'applicazione coinvolta e alla fine la funzione specifica del pacchetto selezionato. Purtroppo spesso è in lingua inglese, comunque si può fare copia-incolla e farsi tradurre il testo on-line ad es. da Google-translate o altro servizio analogo.

In questa scheda è presente un pulsante dal nome “visualizza schermata” che, se schiacciato, in alcuni casi ci permetterà di vedere un immagine dell'applicativo da scaricare. Se schiacciando il pulsante non compare nulla prova ad installare il pacchetto “dwww”.

La scheda “Dipendenze” è particolarmente importante da visionare, per i pacchetti di supporto “consigliati” e “raccomandati”.

La scheda “File installati” permette di capire dove sono andati a finire i file installati col pacchetto. Può essere utile per vedere se c'è un file “readme” o “examples” con utili indicazioni sulle opzioni del pacchetto o un file “changelog” che segnala i cambiamenti rispetto alla versione precedente. Di norma questi tre tipi di file li troviamo in /usr/share/doc.

Molto interessante è la scheda “Versioni”, utile nel caso si desideri compiere un “declassamento” di software. A volte si potrebbe voler declassare un pacchetto ad una versione precedente, magari a causa di problemi sorti con quella nuova. Perchè questo sia possibile è necessario che siano disponibili nei repository versioni precedenti a quella in uso. Per verificare questo aspetto si controlla nella scheda “Versioni” dove verranno elencate le versioni disponibili, se presenti.

Il passo successivo è quello di andare alla “Barra dei Menu” e poi in Pacchetto → Forza versione.

Usate cautela con questa pratica, perchè di norma Synaptic seleziona sempre la versione più recente in grado di mantenere un equilibrio nella rete di interdipendenze tra i pacchetti presenti nei repository di una determinata versione della distribuzione in uso. Forzando una versione diversa da quella di default, si possono verificare errori nella gestione delle dipendenze.

“Cerca” Utilizzare questo pulsante per cercare un pacchetto, digitare una frase, un nome o una versione del programma che si desidera installare. Nella finestra di dialogo che appare non siamo obbligati a inserire l'intero nome. Se, per esempio, si desidera installare il player audio “Amarok”, e si va a scrivere, ad esempio, “ama”, Synaptic mostrerà tutti i programmi che contengono la frase “ama”, quindi anche “amarok”, ma non solo. Questa caratteristica di ricerca è utile in due casi. Nel primo caso immaginiamo di non essere assolutamente sicuri del nome del programma, ad esempio potremmo essere incerti sull'esatto nome, tra “amarok” e “amarock”, digitando il secondo, la ricerca non darà alcun risultato, invece inserendo “amar” o “amaro” lo troveremo agevolmente tra la piccola selezione che Synaptic ci fornirà.

Nota. Per questa caratteristica di estrema precisione, non fidarti ciecamente della funzione “cerca” perchè se sbagli a scrivere nello spazio di ricerca, questa funzione ti darà un risultato nullo e potresti essere portato a pensare che il pacchetto non è disponibile nei tuoi repository. Quando hai un risultato nullo, controlla di persona selezionando “tutti” nell' “area delle categorie” e cercando il pacchetto in ordine alfabetico.

Nel secondo caso, immaginiamo di essere interessati ad un programma adatto a monitorare il livello di inchiostro nella nostra stampante HP. Scrivendo: hp ink (si può chiedere di cercare più di un termine contemporaneamente), mi verranno presentati una serie di programmi (oppure librerie) che hanno a che fare con l'inchiostro e con quella marca. Oppure potrei cercare un programma per gestire il collegamento bluetooth con il mio cellulare: scriverò bluetooth. Se già ho un idea del nome del programma, lo troverò nella lista, se non ho idea guardando in “descrizione” potrò capire a cosa servono i vari pacchetti. Naturalmente se non ho idea del tipo di programma da usare, non guasta una ricerca informativa in internet.

Per questa utile funzione di attinenza con un nome o funzione, lascia la scelta di default “descrizione e nome” nella finestra pop-up “trova” che si ottiene cliccando sul pulsante “cerca”. Le altre opzioni sono molto limitative.
 

2.  Area delle Sezioni - In questa area ci sono 6 pulsanti che indicano i criteri di ricerca dei pacchetti all'interno del sistema.
   
   

Selezionando il pulsante “Sezioni” mi si presenteranno nell'area soprastante “Area delle Categorie” una serie di voci, che indicano delle categorie di suddivisione dei pacchetti. Scegliendo una di queste, mi appariranno, nell'area di fianco a destra, tutti i pacchetti appartenenti a quella categoria.

Selezionando il pulsante “stato” mi si presenteranno nell'area soprastante “Area delle Categorie” una serie di voci, tra cui “installato” per avere, nell'area di destra, l'elenco di tutti i pacchetti installati nel sistema.
Una voce più interessante è “installato aggiornabile” per vedere quali pacchetti possono essere aggiornati.

Col pulsante “Origine” ottengo la lista dei repository installati, ulteriormente suddivisi per sezioni, selezionandone uno, potrò vedere che pacchetti vengono forniti da quel determinato “repo”.

Cliccando sul pulsante “Filtri personalizzati” e poi nell'area superiore “Modifiche selezionate” potrò visualizzare tutti i pacchetti che sono stati selezionati per una qualche azione (installazione, rimozione aggiornamento, ecc.). Interessante è la voce “filtro di ricerca” che per funzionare deve utilizzare la finestra di definizione del filtro, che dobbiamo settare andando nella “Barra dei menù” e da lì in Impostazioni → Filtri.

 

Alcune tipologie di ricerca in realtà sono già ottenibili in maniera più diretta dall'Area n°2 delle Sezioni e dall'area n° 3 “delle Categorie”, ma altre sono inedite. Delle più interessanti tra queste, parleremo affrontando l'argomento “filtri” nella descrizione della “Barra n° 6 dei Menù”.
Sotto alla voce “Filtro di ricerca” voglio menzionare anche “Pacchetti con supporto debconf”.
Il supporto “debconf” consiste nella possibilità da parte di alcuni pacchetti specifici di poter essere ri-configurati in maniera diversa rispetto alla modalità definita al momento dell'installazione.
Una volta attivata questa “riconfigurazione” verranno presentate all'utente-amministratore una serie di domande, le cui risposte permetteranno di riconfigurare il pacchetto-programma.
Perchè questo strumento possa funzionare sarà necessario installare il pacchetto “libgnome2-perl”.
Questo criterio di selezione, si appoggia anch'esso alla finestra di definizione del filtro raggiungibile dalla “Barra dei Menù” e poi: Impostazioni → Filtri → Pacchetti con supporto debconf.
Qui ci assicureremo che sia selezionato tutto (dovrebbe comunque esserlo di default), dopodichè, andando nella “Barra n.°6 dei Menù” in Pacchetto → Configura, potremo attivare questa funzione sul pacchetto selezionato, nell' “Area n.°4 dei Pacchetti”.
Può accadere, raramente, che dei pacchetti non riuscano ad essere installati perché i loro script di installazione falliscono uno o più controlli di sicurezza. Per esempio, un pacchetto potrebbe tentare di sovrascrivere un file che è parte di un altro pacchetto, o richiedere che un pacchetto di dipendenze abbia un aggiornamento maggiore di quello disponibile. Se un'installazione (o aggiornamento) è incappata in uno di questi errori, l'installazione non sarà completa e saremo di fronte ad un pacchetto “danneggiato”.
Se ho il sospetto che possa essere stato installato un pacchetto con degli errori posso controllare la voce “Danneggiato”. Anche in questo caso ho la necessità di raggiungere la finestra di definizione del filtro, andando nella “Barra dei Menu” e poi Impostazioni → Filtri → Danneggiato. Qui ci assicureremo che sia selezionata solo la voce “danneggiato”. Se dovesse risultare davvero un pacchetto corrotto (il pacchetto risulterà evidenziato in rosso) possiamo andare alla “Barra dei Menu” e poi in Modifica → Ripara i pacchetti danneggiati. Se questo non avviene, allora procedere alla disinstallazione del pacchetto.



L'ultima voce è “Raccomandati mancanti”. Dalla lista, che otteniamo, potremo vedere in quali pacchetti, tra quelli che abbiamo, non è stata presa in considerazione l'installazione dei pacchetti di supporto raccomandati. Basterà selezionarli e controllare in “dipendenze” quali pacchetti venivano raccomandati, e se effettivamente non meritavano di essere installati.
In questo caso verifichiamo che sia selezionato tutto in “Barra dei Menù” → Impostazioni → Filtri → Raccomandati mancanti.

3. Area delle Categorie - In essa c'è un elenco che permette di suddividere, per campi di applicazione, i pacchetti-programmi.

Come abbiamo avuto modo di vedere, le voci che compaiono in quest'area variano in base al pulsante selezionato nell' “Area delle Sezioni”
Cliccando su una specifica voce, si ottiene nell'area contraddistinta dal numero 4 “Area dei Pacchetti”, un lungo elenco di pacchetti previsti per quella categoria.
4. Area dei Pacchetti - In questa area viene stilato un elenco di pacchetti raggruppati in base al criterio di selezione definito nell'area n° 3: “Area delle Categorie”.
Da notare che a fianco del nome delle applicazioni è presente un quadrato che può evidenziare dei colori o simboli che indicano il loro stato nel sistema in quel momento.
Per un interpretazione di questi simboli osservate le figure sottostanti:

Basterà cliccare col destro sulla riga di fianco al quadrato, per aprire un menù a discesa che permetterà di aggiornare, rimuovere o installare il pacchetto selezionato:

Come si può notare da questa figura, si possono scegliere due modi per disinstallare un pacchetto: mediante l'opzione “rimuovi” oppure con “rimuovi completamente”
La differenza tra i due è che “rimuovi” disinstalla il pacchetto/programma ma non cancella gli eventuali file di configurazione. Il vantaggio di questa scelta è che reinstallando il programma in un secondo momento, verranno usati i file di configurazione esistenti, risparmiando al sistema di doverli ricreare da zero, lo svantaggio è che se non reistalliamo, ci riempiamo di file inutili e in qualche caso (raro) dannosi per possibili interferenze. In genere sarà quindi da preferire “rimuovi completamente”

5 Area Informativa - Questa area mostra le informazioni riguardanti l'eventuale pacchetto selezionato nell'area 4. Vengono indicate le funzioni dell'applicazione, le dipendenze che la contraddistinguono ed altre interessanti informazioni.

6. Barra dei Menu - In essa si trovano importanti funzioni, come ad esempio l'inserimento (o l'eliminazione) di

Andiamo a vedere le funzioni più interessanti.

Nel primo menu: “file” troviamo l'interessante opzione “salva selezioni come....”. Vediamo di cosa si tratta. 

Selezionando questa opzione comparirà una finestra, si assegna un nome al file e si vista la casellina: “salvare lo stato completo non solo le modifiche”, .Viene creato un file contenente l'elenco di tutti i pacchetti che costituiscono il sistema operativo che stiamo usando e i programmi installati. Saranno presenti i pacchetti presenti nel disco di installazione della nostra distribuzione a cui si sommano (o si sottraggono se abbiamo eliminato programmi) quelli che abbiamo installato successivamente. Questo file potrebbe servire per una reinstallazione. Quindi, quando, dopo un po', sarai sicuro di aver raggiunto una configurazione soddisfacente per te, potrai utilizzare questo file per installare, molto velocemente, anche su un altro computer (o sullo stesso nel caso di una re-installazione), lo stesso tipo di configurazione personalizzata (a parte ovviamente gli eventuali settaggi dei programmi).

Oppure si può ottenere lo stesso risultato con il comando lanciato da console:

# dpkg --get-selections > /home/nomeutente/pacchettimiei.txt

In questo modo avrai ottenuto il file per la tua configurazione. A questo punto sul nuovo computer, dopo aver installato il sistema operativo potrai procedere con l'aggiunta dei programmi supplementari utilizzando “pacchettimiei.txt”, in questo modo: 

Avviare il collegamento internet ADSL e abilitare tutti i repository in Synaptic, chiudiamo Synaptic (tenendolo aperto non si attiveranno i prossimi comandi), procediamo aprendo la finestra del teminale e digitare o copiare i seguenti comandi :

# dpkg --set-selections < /home/nomeutente/pacchettimiei.txt

quindi:

# apt-get dselect-upgrade

Dopo aver dato il consenso all'installazione comincerà il download. Potrebbe essere più pratico avere in mano un file con la differenza tra i pacchetti installati di default e quelli aggiunti da noi, magari per scaricarli e masterizzarli a parte in modo da poterli installare anche senza disporre dell'adsl.

Comunque questo tipo di funzione si può dire che sia superata da utility come MX Snapshot che crea una ISO Live di ripristino del nostro sistema (ma con la possibilità di essere utilizzata anche su altri computer) con tutti i nostri programmi aggiuntivi e senza quelli che abbiamo eliminato ed in grado di mantenere anche i settaggi e le configurazioni personali.

All'interno del menu “modifica” troviamo l'opzione “annulla”, che meriterebbe una maggiore visibilità, magari con un'icona nella barra delle funzioni.

Vediamo perchè è importante. Immaginiamo di voler installare un programma, ad esempio Tuxpaint un semplice editor grafico, il pacchetto da installare si chiama appunto “tuxpaint”, lo cerchiamo nell'elenco dei pacchetti disponibili con la funzione “cerca”, lo selezioniamo, e cliccandoci sopra col destro scegliamo, dal menu a discesa, installa. Richiedere di installare il pacchetto “tuxpaint” comporta l'automatica individuazione e selezione, da parte di Synaptic anche dei pacchetti che ne vanno a costituire le dipendenze permettendo al programma Tuxpaint (in questo caso), una volta installato, di essere completo in tutte le sue parti e poter quindi funzionare.

Nella figura i pacchetti delle dipendenze sono segnati in verde e sono stati automaticamente selezionati da Synaptic. Immaginiamo ora di aver cambiato idea e non voler istallare questo programma, cliccando sempre sul pacchetto principale “tuxpaint” potremo deselezionarlo evitando quindi l'installazione. Questa volta però deselezionare “tuxpaint” non comporta che vengano automaticamente deselezionate anche le dipendenze. Dovremo farlo noi, una per una. In questo caso non è un problema, ma se avessimo già selezionato per l'installazione una decina di programmi e cambiassimo idea sull'ultimo, potremmo non capire più quali sono le sue dipendenze. Si rischierebbe di lasciare nel sistema pacchetti di dipendenze che da soli non servono a nulla e finiscono solo per appesantire il sistema. Questi pacchetti inutili sono detti “orfani”. La funzione “annulla” permetterà di tornare indietro, così che non rimarrà selezionato ne il pacchetto principale ne le dipendenze “orfane”.

Nello stesso menù degna di nota è la voce “aggiungi CD rom” il cui scopo è quello di utilizzare come Archivi di pacchetti CD o DVD invece dei tradizionali archivi on line. Spiegheremo meglio più avanti come procedere.

Nel menù “Pacchetto”, oltre alle classiche voci già viste “installa”, “deseleziona”, “rimuovi”, “aggiorna”, interessanti sono “blocca versione” e “forza versione” dei quali abbiamo già accennato. In merito a “blocca versione” parleremo ancora nella descrizione della modalità di aggiornamento mentre per “forza versione” diamo ancora qualche indicazione.

Soprattutto quando sono stati inseriti diversi repo aggiuntivi rispetto a quelli previsti di default, può capitare che un pacchetto per essere installato abbia necessità di una dipendenza ad una determinata versione, mentre quella installata è ad una versione diversa pur essendo presente quella richiesta dal pacchetto che ci interessa. In questo caso si può andare sul pacchetto della dipendenza ad effettuare un “forza versione”. Ad esempio mi è capitato di voler installare il pacchetto “moonlight” che prevedeva come dipendenza “libavcodec51”, già installata nel mio sistema. All'atto dell'installazione del pacchetto compariva un messaggio “moonlight sta per essere installato ma necessario libavcodec51 versione 2080706, presente versione svn20080206, l'installazione non può essere completata”. Raggiungendo quindi “libavcodec51” nell'Area dei Pacchetti e forzando la versione 20080706, l'installazione di “moonlight” poteva finalmente andare a buon fine.

Comunque come già detto, usate questa funzione solo se strettamente necessario.

Nel menù “Impostazioni” in “preferenze” nella scheda “generale” in “aspetto”, abbiamo: “mostrare le proprietà del pacchetto nella finestra principale”. Si può togliere la spunta, si perderà l' “Area n°5 Informativa” ma si guadagnerà spazio e si potrà usare la più pratica icona “proprietà” nella “Barra delle Funzioni n°1”. Andiamo ora a vedere le altre opzioni di questa scheda. A parte la casellina “chiedere conferma per le modifiche che coinvolgono altri pacchetti” e “Applicare le modifiche in una finestra di terminale” giustamente vidimate di default, abbiamo l'opzione “considerare i pacchetti raccomandati come dipendenze” su cui vale la pena di spendere due parole. Già dal nome “raccomandati” si può capire che sono pacchetti di supporto, non indispensabili ma che è decisamente opportuno installare per disporre di un applicativo completo e funzionale. Tuttavia io sconsiglierei di vidimare questa opzione, meglio invece abituarsi a controllare la scheda dipendenze dell'Area Informativa o dell'icona “Proprietà”, dove mi verranno indicati anche i pacchetti “consigliati”. Se dovessero esserci problemi di conflitti causati da un pacchetto raccomandato sarà più facile individuarlo ed escluderlo installando il resto del programma, inoltre leggendo la descrizione potrò capire se davvero mi serve perchè se non indispensabile potrei preferire un programma più snello e veloce. In un secondo momento potrò sempre riprendere in considerazione le scelte fatte visionando “raccomandati mancanti” nell' “Area n°3 delle Categorie” dopo aver scelto nell' “Area n°2 delle Sezioni” il bottone “filtri personalizzati”. 

Poi, sempre nella finestra della scheda “preferenze” abbiamo l'opzione “aggiornamento del sistema”, con due pulsanti, in cui di default risultano selezionati in quello superiore “aggiornamento intelligente” e in quello inferiore “chiedere sempre”. Queste scelte di norma le migliori, ma vediamo di capire queste opzioni. Vi sono due metodi di aggiornamento che possiamo scegliere con il pulsante superiore: “aggiornamento intelligente” e “aggiornamento predefinito-di default”

L'Aggiornamento predefinito-di default (aggiornamento di tipo “upgrade”) avvia l'aggiornamento solo dei pacchetti già installati. Se un determinato pacchetto, con l'ultimo aggiornamento risulterebbe avere come dipendenze pacchetti non ancora installati oppure che vanno in conflitto con altri pacchetti presenti, l'aggiornamento non viene permesso.

L'Aggiornamento intelligente (aggiornamento di tipo “dist-upgrade”), cerca di risolvere in maniera intelligente i conflitti tra i pacchetti, installando gli eventuali ulteriori pacchetti necessari e preferendo quelli con più alta priorità. E' il sistema di aggiornamento predisposto di default, inoltre qualora si voglia aggiornare un'intera distribuzione passando da una versione a quella successiva, ad es. da Debian Wheezy a Debian Jessie utilizzare questo metodo.

Ad ogni modo, parleremo più avanti degli aggiornamenti di una distribuzione da una “Release” a quella successiva.

Sempre nella scheda “Generale” di Impostazioni, nel campo “Rimozione dei pacchetti:” viene giustamente preferita la scelta “Completamente” pena ritrovarsi in poco tempo con una cache dalle dimensioni di svariati Mega fino a diversi Giga. Comunque controllatela ogni tanto per verificare che venga svuotata regolarmente.

La cache è raggiungibile in /var/cache/apt/archives e può essere svuotata attraverso questo comando del terminale:

# apt-get clean

Un pacchetto contiene al suo interno molti file, con l'installazione quei file ne danno origine ad altri (diversi o semplici copie) che vengono distribuiti in specifiche cartelle di sistema. Quindi completata l'installazione il pacchetto non serve più, a meno che non si voglia fare dei test di configurazione per cui è necessario fare ripetute installazioni e disinstallazioni, oppure si voglia scaricare dei pacchetti da copiare e utilizzare su un computer che non dispone di connessione internet. In questo caso probabilmente si vorrà solo scaricare il o i pacchetti senza che si proceda all'installazione. Quindi dopo aver selezionato “Lasciare nella cache i pacchetti scaricati” e dato OK, si chiuderà Synaptic e si aprirà il terminale per agire con Apt (non lasciate aperto Synaptic contemporaneamente al terminale perché apt-get non funzionerebbe), quindi si darà il seguente comando:

# apt-get install -d xxxx

dove xxxx è il nome del pacchetto da scaricare.

Finita l'operazione e copiato il pacchetto che vi serve ricordatevi di selezionare nuovamente “Completamente” nel campo “Rimozione dei pacchetti”. Poi eliminate dalla cache il pacchetto scaricato, non cancellandolo a mano che creerebbe problemi al database di Apt, ma con il comando visto prima:

# apt-get clean

Terminate le schede di Impostazioni-> preferenze, passiamo ora a Impostazioni-> Repository che ci permette di gestire le fonti on line, che forniscono il software, cioè appunto i repository.

Si aprirà una finestra analoga a questa:

In questa immagine ciascuna riga definisce un repository.

La prima colonna “abilitato” presenta, per ciascun archivio una casellina che, qualora sia presente la spunta, mi indica che l'archivio è attivato. Per disattivarlo basta togliere la spunta. Per eliminarlo del tutto si evidenzierà la riga e si cliccherà sul pulsante “elimina”

Nella seconda colonna “tipo” viene precisato, con la sigla “deb”, se l'archivio contiene pacchetti di binari (chiaramente di tipo debian), e con “deb-src” se si tratta di sorgenti.

Nella terza colonna viene precisato l'url del sito che contiene l'archivio, con la quarta e quinta colonna viene descritto anche il percorso per raggiungere con precisione l'archivio, contenente il software adatto alla nostra distribuzione.

Da questa finestra potrò aggiungere altri repository oltre a quelli previsti di default riempiendo correttamente i campi che abbiamo visto.

Ovviamente dovremo essere sicuri che il repo sia compatibile con la nostra distribuzione e specifica versione, e dovremo possedere l'indirizzo dell'archivio. L'indirizzo ci permetterà di riempire i campi che abbiamo visto, cioè “tipo” “url” “distribuzione” e “sezione”, tuttavia la cosa più semplice è inserire direttamente l'indirizzo dell'archivio in uno dei file dove il sistema memorizza questi indirizzi, ad esempio nel file /etc/apt/sources.list.d/various.list. Nella directory /etc/apt/sources.list.d sono presenti alcuni file dove sono inseriti gli indirizzi degli archivi ad esempio abbiamo un debian.list, un antix.list, un mx.list, il file visto prima ecc. In ogni file in genere ci sono più indirizzi e Synaptic (attraverso Apt) legge l'elenco di questi file e ne crea uno unico che possiamo vedere attraverso la scheda Repository dell'immagine soprastante.

Ad esempio l'archivio selezionato in azzurro nell'immagine è memorizzato nel file “mx.list” così:

deb http://main.mepis-deb.org/mx/repo/ mx15 non-free main

Possiamo anche disattivare il repository “commentandolo”, cioè inserendo il simbolo cancelletto davanti alla riga così:

# deb http://main.mepis-deb.org/mx/repo/ mx15 non-free main

ovviamente per farlo dovremo aver aperto quel file con un editor di testo e i diritti di amministratore.

ATTENZIONE. Dopo aver inserito un nuovo repository, o dopo averne eliminato uno, si dovrà ricaricare la lista dei repository, e quindi dei pacchetti disponibili, nel data base di APT andando a cliccare sul pulsante Aggiorna della barra delle funzioni. Oppure da terminale si darà:

# apt-get update

Poi si andrà in Impostazioni nella barra dei menu e da li in Preferenze → Distribuzione e si controllerà che nel campo “Preferire versioni da:” sia selezionato mx

Ora portiamoci ad Impostazioni → Filtri

Di qualcuno dei filtri, definiti da questa finestra, abbiamo già parlato, ora vediamo se ce ne sono altri interessanti.

Mettendo la spunta su “configurazione residua”, avremo la possibilità di verificare quali pacchetti, in seguito alla loro rimozione dal sistema, hanno lasciato delle tracce di configurazione.

Nota. Il permanere nel sistema delle tracce di configurazione dipende da come abbiamo scelto di disinstallare il pacchetto, vedremo meglio più avanti che possiamo farlo in due modi: mediante l'opzione “rimuovi” oppure con “rimuovi completamente”.

La differenza tra i due è che “rimuovi” disinstalla il pacchetto/programma ma non cancella gli eventuali file di configurazione. Il vantaggio di questa scelta è che reinstallando il programma in un secondo momento, verranno usati i file di configurazione esistenti, risparmiando al sistema di doverli ricreare da zero, lo svantaggio è che se non reistalliamo, ci riempiamo di file inutili e in qualche caso (raro) dannosi per possibili interferenze.

Individuati i pacchetti, per fare “pulizia” basterà cliccarci sopra col destro, e selezionare “rimuovi completamente”.

Altro filtro di un certo interesse potrebbe essere “nuovo nell'archivio” per vedere se dall'ultimo “Aggiorna-Ricarica” che abbiamo dato, sulla barra delle funzioni, sono stati aggiunti nuovi programmi nei repository a cui ci appoggiamo. Segnalo anche il filtro “orfano” che mette in evidenza le dipendenze rimaste “orfane”. Di questo tipo di dipendenze avevamo già parlato a proposito del comando “Impostazioni → annulla” nella “Barra dei Menù”. Qualora non le avessimo eliminate subito grazie a quel comando, possiamo individuarle con questo filtro. Va detto che perchè funzioni sarà necessario aver scaricato il pacchetto “deborphan”.

Installazione di pacchetti con Synaptic

Veniamo quindi all'installazione di un pacchetto. 

Per installarlo procediamo così:

Aprire il programma (Synaptic) e fornire la password di root.

Clicca sul pulsante Aggiorna. Questo pulsante comanda a Synaptic di contattare il server repository on-line e scaricare un nuovo indice con le informazioni sui pacchetti disponibili, in quali versioni, e quali altri pacchetti sono necessari (dipendenze) perchè possa essere installato correttamente.

Utilizzare il pulsante “Cerca” per individuare il pacchetto dell'applicazione che si vuole installare.

Se conoscete il nome del pacchetto/i basterà scriverne il nome, se non lo si conosce con precisione è sufficiente inserire una parola chiave, il nome dell'applicativo o una parte del nome. Synaptic farà una ricerca presentando una lista di pacchetti il cui nome contiene la parola inserita o attinenti a quanto digitato.

Se con il pulsante “Cerca” non compare nulla, provare a cercarlo (dopo aver impostato “tutti” nell'“Area delle Categorie”) direttamente nell' “Area dei Pacchetti” nella lista contenente, in ordine alfabetico, complessivamente tutti i pacchetti presenti nei repositori.

Individuato il pacchetto/i che ci interessa, cliccare con il destro sul quadratino bianco al suo fianco e, nel menu contestuale a discesa, cliccare su “installa”.

Nell'area informativa, o nel pulsante della barra delle funzioni “Proprietà”, sotto “dipendenze” vedremo quali altri pacchetti, necessari a far funzionare il programma, verranno installati assieme al pacchetto selezionato. Qui vengono anche segnalati i pacchetti “raccomandati” e “consigliati”, utili ma non indispensabili. Conviene installare i raccomandati nella maggioranza dei casi mentre per i consigliati (che migliorano o arricchiscono le funzionalità dell'applicativo in questione) farne una valutazione caso per caso.

Verranno inoltre indicati eventuali pacchetti incompatibili con quello che stiamo per installare. In questo caso prima di procedere all'installazione sarà opportuno controllare che nel sistema non vi sia il pacchetto in causa. Attenzione perchè spesso l'incompatibilità è limitata ad una particolare versione, quindi non necessariamente i due pacchetti saranno incompatibili tra loro, perciò andranno prese in considerazione anche le versioni dei pacchetti. Ad ogni modo sarà il sistema stesso a segnalarci un incompatibilità scegliendo a seconda dei casi di non procedere all'installazione, oppure di rimuovere il pacchetto che funge da ostacolo, ma saremo noi a dare la conferma.

Una volta controllato cliccare su "Installa".

Comparirà una finestra di avviso dove verranno indicati quali pacchetti accessori e librerie verranno installati assieme al pacchetto richiesto per far funzionare il programma. In questa finestra vengono elencati anche gli eventuali pacchetti da aggiornare e quelli da rimuovere. E' quindi necessario leggere attentamente quanto elencato.

L'avviso potrebbe non limitarsi a questo. Se abbiamo inserito in “sources.list” dei repository aggiuntivi a quelli previsti di default, senza l'indicazione della relativa chiave di criptazione, allora in questa finestra verremo avvisati che si stanno per installare pacchetti non autenticati, potenzialmente pericolosi.

Vedremo più avanti come fornire la chiave di criptazione, comunque questo avviso può tranquillamente essere ignorato se siamo sicuri che i repo aggiunti sono sicuri e adatti alla nostra distro-versione.

Nella Barra delle funzioni cliccare su "Applica" per avviare il processo di scaricamento e installazione del pacchetto/i

Una nuova finestra di riepilogo chiede la definitiva conferma sull'imminente operazione, in questo caso veniamo informati anche dello spazio che verrà occupato nel sistema. Conviene continuare a leggere tutti i messaggi che vengono riportati, così che se veniamo avvisati che installando un pacchetto, ne vengono rimossi altri, che al contrario non vogliamo rimuovere, si è ancora in tempo per annullare il processo.

Infine cliccare su "Applica"

L'operazione di scaricamento dei pacchetti ha inizio e potrebbe richiedere da qualche secondo a decine di minuti, in base alla dimensione del pacchetto e soprattutto al tipo di connessione. Assicuriamoci che sia selezionata l'opzione “visualizza dettagli” durante lo scaricamento e soprattutto nel sucessivo processo di installazione, così da poter rispondere a eventuali domande di scelta del tipo di configurazione che vogliamo per quel pacchetto (ad es. potrebbe venire richiesta la lingua che vogliamo venga impostata di default). Se non si procede con la risposta l'installazione rimane in sospeso.

Terminato il processo d'installazione ci verrà segnalato con “fatto” o “modifiche applicate”. Si dovrà cliccare “ok” per tornare alla finestra iniziale.

Nota. Quando installi software utilizzando Synaptic assicurati di chiudere il terminale, oppure se vuoi installare usando il terminale e i comandi di apt-get, chiudi Synaptic se è aperto, diversamente si riceverà un messaggio di errore perchè non viene permesso il processo di installazione quando sono contemporaneamente attivati i due sistemi di installazione.

Finita l'installazione, il programma collocherà automaticamente una voce sul MenuStart.

Immaginiamo ad esempio, di aver installato, il pacchetto del programma di editor di suoni “Audacity”, finita l'installazione, andando nel menu generale troveremo nella sezione “Multimedia”, il programma appena scaricato. Se la voce dovesse non comparire, potremmo utilizzare MX Menu Editor per inserirla manualmente all'interno del menu.

Installazione di software utilizzando CD o DVD

La modalità d'installazione del software che abbiamo visto, richiede una connessione a internet, infatti vengono utilizzati archivi on-line, ma si possono installare pacchetti anche utilizzando CD o DVD in cui sono stati riversati i pacchetti dei repository di MX e Debian.

Se avete DVD aggiuntivi per il software fare clic su Impostazioni> Repository. Nella finestra che compare, deselezionare tutti i repository e fare clic su OK. Una finestra di dialogo vi avvertirà che l'elenco dei depositi è cambiato. Cliccare Chiudi.

Dobbiamo ora aggiungere il DVD nell'elenco dei repository.

Vai al menu Modifica> Aggiungi CDROM . Inserire un DVD di software, nell'unità e fare clic su OK. Questo CD verrà letto e identificato con un nome che dovrete confermare. Il nome converrà scriverlo sui dischi, per non rischiare di dimenticarlo quando ci verrà chiesto, le volte successive.

Dopo questa operazione, Synaptic vi chiederà se desiderate aggiungere un nuovo CD o uscire. Se avete altri DVD da aggiungere, seguite la stessa procedura fino all'ultimo disco.

Poi si dovranno aggiornare i repository cliccando su “Aggiorna” sulla Barra delle Funzioni.

A questo punto è possibile installare nuovi programmi.

Selezionare il pacchetto (o pacchetti) da installare e cliccate con il tasto destro del mouse “Installa”. Tenere il DVD a portata di mano, perché verrà richiesto di fornirlo per completare l'operazione.

Rimozione dei pacchetti

Vediamo ora come procedere alla rimozione di un pacchetto.

Rimoziuname -rone di software con Synaptic

Le operazioni da svolgere per rimuovere il software con Synaptic risultano essere ancora più semplici dell'installazione, ma a livello di sistema la cosa è un po' più complessa di quel che potrebbe sembrare, per la rete di interconnessione del software di cui si è già parlato.

Effettuare la ricerca del pacchetto che si intende rimuovere. Per farlo cliccare su "Cerca" della Barra delle Funzioni. Nell'Area dei pacchetti individuare il pacchetto.

Cliccare con il destro sul quadratino verde al suo fianco e nel menu contestuale selezionare “Marca per la rimozione” o “Marca per rimozione completa”.

"rimuovi" disinstalla il software, ma lascia i file di configurazione nel caso in cui si desideri mantenere le impostazioni.

"rimuovi completamente" rimuove il software e i file di configurazione. Quest'operazione è detta “fare il purge (o il purging) di un pacchetto”. Questa di norma è il tipo di rimozione preferibile.

Quando altri programmi dipendono da un pacchetto che viene rimosso, anche i pacchetti di questi programmi verranno rimossi. Questo accade di solito quando si rimuovono pacchetti di “librerie” (pacchetti che iniziano con "lib"), oppure servizi che fanno da supporto ad altre applicazioni, che senza questi pacchetti non potrebbero funzionare.

Una finestra indica quali sono i pacchetti accessori e le librerie che verranno rimossi.

La rimozione di applicazioni di grandi dimensioni che si compongono di molti pacchetti può creare complicazioni.

E' quindi necessario leggere attentamente quanto elencato, prima di fare clic su OK, per la disinstallazione.

Nella Barra delle funzioni cliccare su "Applica" per avviare il processo di rimozione del pacchetto.

Occasionalmente, durante una disinstallazione, i conflitti nelle dipendenze dei pacchetti possono determinare la richiesta di disinstallazione di un gran numero di pacchetti importanti. Questo è raro, con la configurazione di default, ma diventa sempre più probabile quando sono stati immessi repository aggiuntivi, soprattutto se non sono del tutto compatibili. Stare quindi molto attenti ogni volta che l'installazione di un pacchetto richiede che ne vengano rimossi altri!

Se si viene avvisati che verranno rimossi un gran numero di pacchetti, conviene cercare un altro metodo per installare o disinstallare quell'applicazione.

Molte volte questi pacchetti sono installati utilizzando un meta-pacchetto, che è un pacchetto vuoto che contiene all'interno solo un elenco di dipendenze cioè elenca tutti i pacchetti necessari ad una determinata applicazione. Il modo migliore per rimuovere un pacchetto complesso come questo è di ispezionare l'elenco delle dipendenze del meta-pacchetto, e rimuovere i pacchetti elencati. Prestare attenzione, tuttavia, a non disinstallare una dipendenza di un'altra applicazione che si desidera conservare!

Una volta completata l'operazione una ulteriore finestra indica che il pacchetto è stato rimosso. Per avere conferma della rimozione, basta cercare nuovamente il pacchetto e si noterà che il quadratino alla sinistra è diventato di colore bianco, che sta ad indicare che il pacchetto non è installato.

Aggiornamento dei pacchetti

Synaptic permette di mantenere il software aggiornato in maniera semplice e rapida.

Quando si utilizza per la prima volta Synaptic, vi verrà proposto di aggiornare l'elenco dei pacchetti. conviene accettare la proposta. Se non vi venisse proposto, vi consigliamo di effettuarlo comunque di vostra iniziativa, facendo clic sul comando “Aggiorna” (o update).

Prima di procedere con gli aggiornamenti è possibile scegliere che tipo di aggiornamento si voglia fare.

Esistono due possibilità. L' “aggiornamento intelligente” e “aggiornamento predefinito-di default”

L'Aggiornamento predefinito (“upgrade”) avvia l'aggiornamento solo dei pacchetti già installati. Se un determinato pacchetto, con l'ultimo aggiornamento risulterebbe avere come dipendenze pacchetti non ancora installati, oppure che vanno in conflitto con altri pacchetti presenti, l'aggiornamento non viene permesso.

L'Aggiornamento intelligente (“dist-upgrade”), cerca di risolvere in maniera intelligente i conflitti tra i pacchetti, installando gli eventuali ulteriori pacchetti necessari e preferendo quelli con più alta priorità.

A dispetto del nome, questo è il tipo di aggiornamento previsto di default in MX ed effettivamente è quello preferibile in condizioni normali.

Se si volesse fare una propria scelta tra queste due modalità di aggiornamento si dovrà raggiungere la “Barra dei Menu” → Impostazioni → Preferenze → Aggiornamento del sistema

Per vedere tutti i pacchetti installati nel proprio sistema in grado di essere aggiornati, cliccare sul pulsante in basso a sinistra nell' “Area delle Sezioni” e selezionare la categoria “installato (aggiornabile)” nel riquadro in alto.

Synaptic vi informerà se esistono pacchetti aggiornabili contrassegnando con una stella, il quadrato di fianco al nome.

Selezionare il pulsante “Seleziona aggiornamenti” per aggiornare tutti questi pacchetti in una volta, oppure fare clic su un singolo pacchetto per selezionarne l'aggiornamento singolarmente.

Cliccare su Applica per attivare l'aggiornamento.

Quando il processo di installazione inizia, hai la possibilità di guardare i dettagli in una finestra di terminale all'interno di Synaptic.

Nota. Con l'aggiornamento di alcuni pacchetti, è possibile che si presenti una finestra di dialogo in cui venga chiesto di immettere informazioni di configurazione, o decidere di sovrascrivere un file di configurazione che è stato modificato rispetto a quanto previsto di default. Prestare attenzione a quanto richiesto in questa fase. Quando viene chiesto se si desidera installare (replace) la nuova versione, anche nota come "la versione del manutentore del pacchetto" o di tenere (keep) la versione corrente, la risposta più sicura di solito è di mantenere la versione attuale (N), che in genere è la scelta di default. Se però il pacchetto in questione proviene da un repository MX, si consiglia invece di dire "sì" (Y).

Bloccare il software con Synaptic

A volte si potrebbe voler bloccare ad una versione specifica i pacchetti di un'applicazione, in modo da evitare possibili problemi, di cui sei a conoscenza, con gli aggiornamenti alle versioni più recenti.

E' questo il caso, per esempio, del Kernel. Gli aggiornamenti del Kernel possono risolvere eventuali bug di sicurezza o apportare migliorie importanti al sistema. Tuttavia un aggiornamento, magari avvenuto in maniera automatica, può determinare la perdita di alcuni settaggi (ad esempio della scheda video o di alcuni moduli compilati su misura del kernel) creando problemi all'utente. Di norma i settaggi non si perdono e non si hanno problemi inoltre quando si installa un nuovo kernel viene mantenuto quello precedente per cui se qualcosa non funziona si può sempre scegliere quale kernell utilizzare per il boot.

Potenzialmente più pericoloso è il caso di pacchetti compilati da noi, ma in genere non è una pratica con cui si cimentano i principianti, comunque in questi casi il blocco della versione è facile da fare con Synaptic:

Aprire il programma, fornire la password di root, e fare clic su “Aggiorna”.

Trovato ed evidenziato, il pacchetto che si vuole bloccare, andare sulla barra dei menu, e cliccare su Pacchetto -> Blocca versione

Synaptic evidenzierà con una colorazione rossa il pacchetto e mostrerà un lucchetto sul quadratino accanto al nome del pacchetto.

Per sbloccare, evidenziare nuovamente il pacchetto e fare clic su Pacchetto -> Blocca la versione (che in questo caso, mostrerà un segno di spunta).

Nota. Questo blocco funziona solo se si utilizza Sinaptic per scaricare o aggiornare il software, non funziona se si utilizzano altri strumenti (ad esempio APT) per l'aggiornamento.

Aggiornare la distribuzione alla versione successiva.

Alcune distribuzioni (chiamate rolling distro) tra cui Debian hanno la possibilità di passare da una versione a quella successiva (ad es. da Debian Wheezy a Debian Jessie), semplicemente attraverso un aggiornamento dell'intero sistema, del kernel e dei repository, senza dover quindi effettuare una re-installazione della distribuzione. Non si tratta di un sistema infallibile, alle volte saranno necessari piccoli aggiustamenti “manuali” che per un principiante potrebbero costituire una perdita di tempo maggiore di una re-installazione da zero.

Nel caso di antiX MX Linux possiamo parlare di “semi-rolling”. Per capire meglio il concetto va detto che Debian, su cui si basa antiX MX, cambia versione circa una volta ogni 2 anni, mentre antiX MX cambia versione una volta all'anno. Se al passaggio alla versione successiva di antiX MX, Debian non è ancora avanzata alla versione successiva all'ora si potrà fare l'avanzamento di versione senza teoricamente incorrere in problemi come una normale rolling, se c'è stato un avanzamento anche in Debian i rischi sono maggiori e la cosa diventa maggiormente sconsigliabile. Io in genere consiglio di lasciare libera una partizione sul proprio sistema proprio per installare la versione successiva e aggiungerci le varie migliorie con calma potendo contare sulla vecchia versione collaudata che continua a lavorare a dovere. In genere ogni versione viene supportata per molti anni, per cui non c'è bisogno di abbandonarla tanto in fretta.

Comunque vediamo come procedere, ma si consiglia di fare una prova su una macchina virtuale ad esempio utilizzando Virtualbox usufruendo magari di MX Snapshot per realizzare una ISO installabile del nostro sistema con le nostre modifiche:

• Procedere con un preventivo update e Aggiornamento intelligente “dist-upgrade” dei pacchetti presenti nel sistema.
• Ora procedere a sostituire nei file presenti in /etc/apt/sources.list.d la lista dei repository della vecchia versione con gli url dei nuovi repo. Fate prima una copia di sicurezza dei vecchi file.

• Scaricate via Synaptic (o apt) il pacchetto del kernel della nuova versione.il nuovo kernel. Immaginiamo che il kernel della vecchia versione sia: linux-image-4.4.10-antix.1-686-smp-pae mentre quello della nuova: linux-image-4.8.1-antix.1-686-smp-pae
  Nota. Sarà opportuno che ambedue i kernel posseggano la stessa architettura a 32 o 64 bit.
  Scaricate anche il realativo file degli headers, ad esempio in questo caso:
  linux-headers-4.8.1-antix.1-686-smp-pae
  Apt-Synaptic vi chiederanno se volete installare il nuovo Kernel, ditegli di si.

• Finita l'installazione date questo comando:
  # update-grub
  a questo punto effettuate il reboot il nuovo kernel dovrebbe essere collegato alla voce principale col nome della distribuzione, ad esempio MX 15 su /dev/sda1. Avviate quando si apre il desktop controllate che kernel state usando dando questo comando da terminale:
  $ uname -r oppure controllate in MenuStart →Sistema →System profiler and Benchmark →Operating Sistem. Se non dovesse essere il nuovo Kernel allora riavviate e lo dovreste trovare alle voci del boot che si aprono selezionando Opzioni Avanzate, in questo caso Opzioni Avanzate di MX 15 su /dev/sda1
  Riavviate con il Kenel corretto ed eventualmente intervenite con MenuStart →Sistema →Grub Costumizer per riorganizzare la lista con cui si presenta il boot.
• Aprire Synaptic e procedete con “Aggiorna” (update) e Aggiornamento intelligente “dist-upgrade” dei pacchetti. Disattivate preventivamente eventuali repository debian-backports o altri non indispensabili.

I Repository

Il software messo a disposizione dalle distribuzioni, sia che si tratti di sorgenti da compilare, oppure in misura maggiore di pacchetti, viene organizzato e indicizzato in appositi archivi così da poter essere facilmente scaricato ed installato attraverso un unico sistema centralizzato che fa uso di appositi gestori (Synaptic, Apt, ecc.).

Quando installiamo una distribuzione, nei file contenuti in /etc/apt/sources.list.d vengono elencati i siti, previsti di default, contenenti archivi da cui i programmi, come Synaptic, attingeranno per aggiornare e installare software.

In questi files di “sources.list” ciascun url non indica semplicemente il sito, ma descrive anche il percorso per raggiungere con precisione l'archivio contenente il software adatto alla nostra distribuzione. Questi archivi, vengono chiamati “repository”.

Alcuni siti contengono diversi archivi validi per varie distribuzioni linux, altri sono specifici per una sola.

In questi server troveremo una directory col nome della distro di cui contengono il software, all'interno di questa troveremo una cartella riferita alla versione della distribuzione (ad es. mx14, mx15 oppure per Debian: stable, testing, ecc.), questa a sua volta conterrà un altra cartella (la cartella della sezione) con un nome (main, contrib, non-free, ecc.) che farà riferimento alle caratteristiche del software contenuto.

Come abbiamo visto nei paragrafi precedenti, Synaptic fa uso di un procedimento specifico per installare o rimuovere le applicazioni. In questa attività i file contenuti in /etc/apt/sources.list.d con il loro elenco di repository, vengono sistematicamente coinvolti. Ognuno di questi file è un semplice file di testo modificabile con un editor di testi.

Aperto il file, si noterà la presenza di righe di testo precedute o meno dal segno di cancelletto (#). Questi simboli, quando sono presenti, disattivano la riga di testo che li segue, si dice che “commentano” la riga.

Le righe, nel nostro caso, sono costituite da Url cioè indirizzi internet che individuano i repository, cioè gli archivi di software. Questi url descrivono il percorso per raggiungere l'archivio, e contemporaneamente aiutano a individuare con facilità la natura, il contenuto e l'origine del software che vi è contenuto.

Ad esempio potremo trovare questa riga:

deb http://ftp.it.debian.org/debian/ stable main contrib non-free

Nel primo elemento: “deb” viene precisato se l'archivio contiene pacchetti (chiaramente di tipo debian), oppure sorgenti. In questo secondo caso la sigla sarebbe:“deb-src”.

Nel secondo elemento: “http://ftp.it.debian.org” viene precisato l'url del “sito” che contiene l'archivio. Un sito con questo tipo di funzioni viene chiamato “server”.

Il terzo indica per quale distribuzione è fornito il software.

Il quarto indica la versione. In questo caso “stable”, corrisponde alla versione della distribuzione Debian che attualmente è “Jessie”.( "Jessie", è la versione stable su cui è basata antiX MX 15)

Al posto di stable potremmo vedere scritto stable/update il che indica che si tratta di un repository dove vengono forniti gli aggiornamenti di sicurezza per Debian stable.

Nota. In questo periodo, Debian testing è “Stretch” e “Sid” è unstable (la versione unstable è sempre chiamata Sid).

Dopo circa due anni di perfezionamenti una versione debian testing passa in stable, la stable passa in old-stable e così via. Quindi tra non molto “Stretch” diventerà stable e “Jessie” old-stable.

In definitiva per indicare la versione di debian adatta a MX 15, potremo trovare l'indicazione di

• stable oppure jessie.

In altri repo, avremo:

• deb-multimedia jessie: contiene pacchetti di software multimediale. E' presente nella lista dei repository ma è disabilitato di default, esattamente come nella distribuzione Debian. E' comunque importante averlo perché permette di scaricare alcuni codecs importanti. La maniera più sicura per scaricarli è usare MX Package installer, che li scarica e disabilita automaticamente il repository. Viene disabilitato perché il software in esso contenuto non è considerato così stabile come quello del repository principale di Debian, tuttavia molti utenti lo tengono abilitato senza lamentare problemi.
• security: contiene solo pacchetti di aggiornamenti relativi alla sicurezza.
• antix jessie: contiene i pacchetti peculiari di questa distribuzione che permettono di differenziarla da Debian. Oltre ai pacchetti peculiari di antiX come quelli relativi ai numerosi strumenti, vi sono anche pacchetti che sono stati ricompilati da Debian test per avere software aggiornato su una base stabile.
• mx-x.x:. x.x sta ad indicare il numero della versione di MX (ad es. 15). Vi sono i pacchetti realizzati per MX che su una antiX classica non servono, come quelli relativi ad alcuni strumenti di MX Tools non presenti nella versione classica, e alcuni pacchetti a cui è stato fatto il backport da Debian Test.
• mx15 test: rappresenta l'archivio dove vengono inseriti i pacchetti che sono stati recentemente realizzati oppure ricompilati da Debian Test e hanno bisogno di un certo tempo di verifica prima di essere inseriti nel repo ufficiale. L'uso di questo repository viene facilitato da MX Test Repo Installer, che consente all'utente di sfogliare ed installare pacchetti da questo repo che come configurazione predefinita è disabilitato per questioni di stabilità. Se si vuole fare da tester o si vuole una versione più recente di un determinato software allora MX Test Repo Installer farà vedere quali pacchetti sono disponibili consentendone l'installazione senza la necessità di abilitare prima il repo testing. Il repo test sarà attivato lo stretto necessario per installare le applicazioni selezionate e poi disattivato automaticamente.

Dopo l'indicazione della versione: “stable”, “testing” e “”unstable”, troviamo la sezione, il cui nome ci fa capire che tipo di software vi è contenuto:

• main: contiene il 90% del software proposto di default da Debian,
• contrib: contiene software che rispetta i punti 5 e 6 della DFSG (debian free software guideline), ma che dipende da pacchetti che non la rispettano.
• non-free: contiene software che possiede limitazioni particolari a causa della licenza di pubblicazione.

Se un repository contiene gli archivi di più sottosezioni, nell'url si vedranno le sottosezioni presenti. Ad es.:

deb ftp://ftp.debian.org/debian/ jessie main contrib non-free

Ai repository di default se ne possono aggiungere molti altri, semplicemente aggiungendone lo specifico url in una riga, sotto quelle già presenti, nei file della cartella /etc/apt/sources.list.d, ad esempio potremmo inserirli in /etc/apt/sources.list.d/various.list. Occorre pero' prestare attenzione a non aggiungere repository incompatibili con la distribuzione in uso.

MX 15 viene fornito con una serie di repo attivati che ti offrono sia una discreta quantità di software sia garanzie di sicurezza e stabilità. Se siete principianti con antiX MX (e soprattutto se lo siete con Linux in generale), si raccomanda, in linea di massima, di utilizzare i repository previsti di default, almeno per un primo periodo.

MX Linux 15 è “binario-compatibile” con Debian Jessie. Ciò significa che il software compilato per funzionare su Lenny sarà in grado di essere eseguito senza modifiche su MX Linux 15. Installando pacchetti provenienti da repository predisposti per le versioni più recenti di Debian, (oppure più vecchie) o ancora peggio per Ubuntu, può facilmente causare instabilità del sistema. Chiaramente il discorso vale anche se si volesse utilizzare i repo di MX 14 per MX 15, o viceversa.

Se per qualsiasi motivo si è persa la lista dei repository, o non si sa più cosa dovesse essere disabilitato e cosa no o si pensa che ci sia stato un cambiamento nei server di qualche repo, si può controllare l'elenco ufficiale qui: https://mxlinux.org/wiki/system/repos-mx-15

Repository sono facilmente aggiunti, rimossi, attivati o disattivati attraverso Synaptic come abbiamo visto nei paragrafi precedenti, ma la stessa cosa si può fare anche andando a modificare direttamente i file in /etc/apt/sources.list.d con un editor di testo con i privilegi di root.

Un modo pratico per fare questo può essere quello di aprire il terminale, acquisire i diritti di root, digitare

thunar

e dare invio. Si aprirà il window manager thunar e tutto ciò che apriremo verrà fatto con i diritti di amministratore, quindi raggiungeremo la cartella /etc/apt/sources.list.d e i vari file contenuti all'interno.

Per esempio, se volessimo inserire il repo jessie backport:

deb http://www.backports.debian.org/debian jessie-backports main contrib non-free

basta fare un semplice copia e incolla, in qualità di amministratore, nel file /etc/apt/sources.list.d/debian.list e salvarlo.

Poi si dovrà ricaricare la lista dei pacchetti dei repo facendo un “update”

# apt-get update

Nota. il repo backports è un classico repo che completa quelli ufficiali in debian stable. Contiene i pacchetti delle versioni più aggiornate di Debian (testing) che sono stati ricompilati per adattarsi a Debian Jessie, così da avere software avanzato anche su una Debian stable. Ovviamente il software in questione è meno sicuro di quello ufficiale di debian stable.

Non sempre un repository contiene il software di vari applicativi e programmi, talvolta è specifico per uno solo, ed in genere viene messo a disposizione dalla stessa società che sviluppa il programma.

Se per esempio si volesse installare il browser Opera, si potrebbe scaricare sul disco fisso l'eseguibile, e poi installarlo, oppure per questo tipo di software vi è la possibilità di inserire l'url del repo specifico.

Inserendo l'url in sources.list sarà il sistema centralizzato di gestione del software (apt/synaptic) a occuparsi dell'installazione, gestione delle dipendenze, disinstallazione, ecc.

In questo caso l'url da copiare sarà:

deb http://deb.opera.com/opera stable non-free

Nota. Anche in questo caso, non basta che il repository si riferisca a Debian, deve essere allineato con la debian-stable a cui si appoggia la versione corrente di Mx, che in questo momento è jessie, diversamente si rischia di rendere instabile il proprio sistema e di danneggiarlo

Gestire le chiavi di autenticazione

Alcuni di questi repo per essere letti hanno bisogno dell'installazione di una chiave pubblica, una specie di certificazione, cioè una firma digitale con funzioni di sicurezza, il che assicura l'utente che i pacchetti di quel repo siano autentici perchè difesi da una chiave di crittografia.

Se si installano i pacchetti di quel repo senza la chiave, verrà visualizzato un messaggio di avviso che si stà per installare software che non può essere autenticato. Il software in questi casi si installa correttamente comunque, tuttavia per avere certezza che le installazioni siano sicure e per liberarsi di questo avviso è necessario installare le chiavi che non erano già presenti di default.

La cosa più semplice da fare è utilizzare l'applicazione MX Check Apt Gpg presente in MX Tools.

Vediamo ora di capire meglio cosa sono queste chiavi di crittografia e sistemi alternativi per gestirle, nel caso che MX Check Apt Gpg avesse dei problemi a reperirne qualcuna.

Il manutentore di un repository per firmare il suo repo genera, mediante un apposito programma, una coppia di chiavi pubblica/privata. La chiave privata, protetta con una password viene conservata dal manutentore stesso. La chiave pubblica deve essere condivisa con gli utenti che intendono usufruire del repository.

Il manutentore del repo, per condividere la chiave pubblica può utilizzare differenti modalità:

La chiave pubblica viene criptata in un file di testo e poi può essere semplicemente importata dagli utenti prelevandola dal luogo dove il manutentore conserva quel file (spesso chiamato Release.gpg) che in genere è all'interno del repo, eseguendo un comando del tipo:

# wget http://www.indirizzo_chiave/public.key -O- | apt-key add -

naturalmente l'utente dovrà conoscere l'indirizzo della chiave, questa informazione normalmente è reperibile nella home-page del repo.

Nota. I file della chiave pubblica (in genere chiamati Release.gpg) contengono un testo crittografato di questo tipo:

-----BEGIN PGP PUBLIC KEY BLOCK-----

Version: GnuPG v1.4.1 (GNU/Linux)

mQGiBEqbsVsRBACY1CgyoV0nd3aTEMxl+XABdmBon9Q0BfJpoMUD3aN4RSeiopnm

Q72BXkVKWFcGiTXhraitCp9+eRh0Q6xKO+sA8P.............

...........................9N4le8ACfQW1D4kgDMXucEuFYDZo2LV4jbus=

=wGGg

-----END PGP PUBLIC KEY BLOCK-----

In alternativa la chiave viene esportata dal manutentore su un apposito server di chiavi (keyserver), in questo caso gli utenti possono importare la chiave pubblica da quel server, con questi comandi in successione:

$ gpg --keyserver [indirizzo_keyserver] --recv-keys [ID CHIAVE]

$ su (invio password invio)

# gpg --armor --export [ID CHIAVE] | apt-key add -

sostituendo opportunamente [ID CHIAVE] e [indirizzo_keyserver]

Nella parte finale di questi comandi, sia nel primo che nel secondo caso, con “apt-key add -” si importa la chiave nel portachiavi del proprio sistema dove vengono conservate queste chiavi, cioè nel database di gnupg, in liste all'interno di file criptati presenti in /root/.gnupg.

Vi è comunque la possibilità, di ottenere la chiave di autenticazione, semplicemente installando il pacchetto che la contiene. La maggior parte dei repository permette di istallare un apposito pacchetto con la chiave. Cerca “keyring” in Synaptic, verranno visualizzati una serie di pacchetti con nomi analoghi a questi (che sono tra più comuni pacchetti di chiavi debian):

gnome-keyring

debian-archive-keyring

debian-multimedia-keyring

Controllando in “Proprietà”, sulla barra delle funzioni di Synaptic, si può capire se, tra quelli selezionati, c'è il pacchetto delle chiavi che stiamo cercando.

Un altra possibilità è quella di prendere nota del messaggio che ci avvisa della mancanza della chiave.

Supponiamo che dopo aver aggiunto un nuovo repository alla vostra sources.list e aver eseguito una ricarica della lista dei pacchetti (update), cioè cliccato il pulsante “Aggiorna” in Synaptic, venga fornito un messaggio simile a questo:

“Si è verificato un errore.

W: GPG error: http://mirror.noreply.org lenny Release: Le seguenti firme non sono state verificate perché la chiave pubblica non è disponibile: NO_PUBKEY CFF71CB3AFA44BDD”

Questo significa che bisogna autenticare il repo (in questo caso “noreply”) scaricando la relativa chiave gpg. Per farlo utilizziamo il numero alfanumerico (in questo caso CFF71CB3AFA44BDD) che vediamo alla fine del messaggio, che rappresenta l' “'id della chiave” pubblica, di quel repository.

Poiché le chiavi di autenticazione gpg vengono solitamente pubblicate dal manutentore del repository all'interno di appositi server pubblici per la gestione di queste chiavi, interrogheremo questo sito fornendogli l'id della chiave pubblica che avremo copiato dal messaggio di avviso.

Il comando utilizza la seguente sintassi:

$ gpg --keyserver [nome del server] --recv-keys [id della chiave]

Quindi, considerando che uno dei server più utilizzati come archivio di queste chiavi è http://subkeys.pgp.net , nel caso del repository mostrato prima, il comando da dare sarà:

$ gpg --keyserver subkeys.pgp.net --recv-keys CFF71CB3AFA44BDD

ottenuta la chiave gpg dal server, dovrà essere immessa all'interno del database delle chiavi del nostro sistema, con questo comando, questa volta con i privilegi di amministrazione:

# gpg --export --armor [id della chiave] | apt-key add -

continuando con l'esempio di prima sarà:

# gpg --export --armor CFF71CB3AFA44BDD | apt-key add -

Attenzione al trattino alla fine del comando!

A questo punto va fatto l'update, da sinaptic oppure da terminale, così:

# apt-get update

Nota. Se dal server segnalato, non si riesce ad ottenere nulla si può provare a cambiare server, ad esempio

minsky.surfnet.nl

search.keyserver.net

wwwkeys.pgp.net

pgp.dtype.org

wwwkeys.eu.pgp.net

keyserver.linux.it

Altri sistemi per la gestione dei pacchetti Debian

Prima o poi alcuni software che si desidera installare non saranno disponibili nei repository on line, nemmeno in quelli “aggiuntivi”. Si potrebbe aver bisogno di un programma particolare reperibile solo scaricandolo da qualche sito web o dal cd di qualche rivista linux. Potrebbe essere stato pacchettizzato nel formato debian “.deb” o in altri formati , oppure essere disponibile in codice sorgente, potrebbe quindi rendersi necessario utilizzare altri metodi di installazione specifici. Vediamo intanto come comportarci di fronte ai pacchetti .deb. Dopo aver descritto l'uso di Synaptic, parleremo di altri tool di installazione che possono venir impiegati allo scopo suddetto. Cominceremo a descrivere il funzionamento di Apt, che in realtà viene utilizzato (così come Synaptic) per l'installazione di software ricavato dai repository ma che può affiancare i tool specifici per pacchetti ottenuti da altre fonti a risolvere dipendenze o complicazioni. Più avanti affronteremo anche altre tipologie di pacchettizzazione, e l'installazione di software distribuito in forma di codice sorgente.

I pacchetti di software installati tramite Synaptic (e APT che ne costituisce il “motore”, infatti Synaptic rappresenta la veste grafica di Apt) sono in un formato chiamato .deb (abbreviazione di "Debian", la distribuzione Linux che ha elaborato APT).

Tra gli strumenti a riga di comando per installare pacchetti software con estensione .deb i più importanti sono Apt e Dpkg.

Il primo, più evoluto, sta alla base di Synaptic , mentre il secondo opera a livello ancora più basso e a differenza di Apt e Synaptic non è indicato per l'installazione di pacchetti .deb da scaricare da specifici archivi presenti nella rete internet (i repo) quanto piuttosto ad installare i pacchetti già presenti nel nostro hard disk.

Per questi ultimi, oltre allo strumento a riga di comando Dpkg, si può usare il tool grafico Gdebi. Quest'ultimo in realtà è da preferire a Dpkg perché si occupa di controllare la presenza delle dipendenze prima di installare il pacchetto.

Dpkg è un installer / de-installer di pacchetti già presenti nel proprio computer. Non funziona via Internet come Sinaptic, o Apt. Dpkg può installare solo un pacchetto .deb che sia già stato scaricato (o copiato) nel sistema.

Gdebi così come Dpkg, viene utilizzato per l'installazione di pacchetti .deb, che abbiamo ottenuto per vie alternative ai repository della nostra distribuzione. Dispone di una comoda interfaccia grafica ma può essere utilizzato anche da riga di comando. Contrariamente a dpkg non si limita ad installare un pacchetto deb, ma si occupa di soddisfarne prima le dipendenze in modo automatico tramite Apt.

Per quanto riguarda Apt, ricordate che Apt (e Synaptic che ne rappresenta l'interfaccia grafica) non è adatto per l'installazione di pacchetti già presenti nel nostro hard disk, ma per quelli disponibili nei repository indicati nei file di configurazione presenti in /etc/apt/sources.list.d

Una menzione a parte va fatta per MX Installa Meta-pacchetti – MX Package Installer in realtà non è un vero programma per la gestione del software, in sostanza installa meta-pacchetti dai repository appogiandosi ad Apt, non sostituisce l'uso di Apt o di Synaptic ma può essere molto comodo e utile usarlo in alcuni casi.
A differenza dei normali pacchetti, i meta-pacchetti non contengono realmente software, ma semplicemente dipendono da altri pacchetti, così basta installare un pacchetto per scaricarne automaticamente diversi che insieme realizzano un software completo per determinati fini. I metapacchetti possono ad esempio fornire un ambiente desktop completo o un programma con i suoi plugin.

I metapacchetti servono fondamentalmente a fornire un prodotto unificato e semplificato all'utente finale, il quale può installare un intero "set" di programmi tramite un solo metapacchetto, invece che installare singolarmente tutti programmi forniti dai vari pacchetti.

Ad esempio questo programma è utile immediatamente dopo l'installazione della distribuzione perché è possibile scaricare in un colpo solo tutti i pacchetti che consentono la localizzazione italiana del sistema e dei principali programmi. Sulla schermata di apertura andare alla sezione “language” e vidimate la casellina “Italian”, “Italian LibreOffice” e “Italian Firefox”. Poi conviene andare alla sezione “Misc” e vidimare la casella “java”.

Nota. Per completare l'istallazione basterà scaricare i codecs proprietari multimediali con MX Codecs Installer e flash con MX Flash Manager.

                                               APT                                                        

Apt è stato creato per rendere più semplice l’utilizzo di dpkg, il vero gestore di pacchetti Debian. Lo scopo di APT è gestire le dipendenze dei pacchetti, chiamare dpkg e rendere indolore l’installazione di software grazie alla ricerca e all'installazione delle dipendenze che viene fatta al posto vostro.

L' apt-system creato dagli sviluppatori di Debian e' un insieme di scripts che si appoggiano al comando dpkg e tentano di snellire/agevolare la gestione di pacchetti e dipendenze nei sistemi Debian GNU/Linux. Lungi dall'essere completa, questa brevissima panoramica ha lo scopo di fornire un piccolo vademecum per mostrare come è possibile gestire i pacchetti software senza far ricorso a tools grafici che in qualche caso potrebbero non essere pratici, come nel caso in cui si voglia scaricare un discreto numero di pacchetti in un colpo solo, inoltre alcuni di questi comandi potrebbero essere utili per superare situazioni di emergenza in cui Synaptic possa essersi bloccato. Vediamo brevemente i principali comandi (ovviamente dovete essere root):

apt-get install [pacchetto1 pacchetto2 pacchettoN ...]: Questo comando prende l'ultima versione disponibile del pacchetto specificato e la installa, insieme a qualsiasi altro pacchetto da cui eventualmente dipenda, infatti Apt installando i pacchetti ne risolve le dipendenze.

Se il pacchetto specificato risulta già installato ne viene fatto l' aggiornamento.

apt-get remove [pacchetto1, pacchetto2, pacchettoN, ...]: Serve a rimuovere un programma installato.

Dato che alcuni pacchetti software dipendono da altri per poter funzionare, la rimozione di un programma può causare il malfunzionamento di altri. L' uso di apt-get remove permette di controllare queste dipendenze e, se trova pacchetti che necessitano di quello che stiamo rimuovendo, avviserà che stà per rimuovere anch' essi. Ad esempio se diamo questo comando per eliminare un pacchetto che è una dipendenza di qualche altro software, che quindi poi non funzionerà correttamente, Apt ci avvisa che insieme al pacchetto richiesto eliminerà anche quest'ultimo programma (o meglio i pacchetti che lo compongono). In questo modo possiamo renderci conto delle conseguenze di ciò che stiamo facendo.

Va detto che apt-get remove rimuove il pacchetto ma non i suoi file di configurazione, per eliminare anch'essi è necessario anteporre --purge a remove. Nella maggioranza dei casi per mantenere un sistema pulito sarà bene eliminare anche i file di configurazione e quindi usare apt-get --purge remove, a meno che per qualche motivo non si voglia disinstallare un software che poi si intende reinstallare e si voglia ritrovare già le configurazioni pronte e personalizzate, come erano state lasciate nella precedente installazione.

apt-get --purge remove [pacchetto1, pacchetto2, pacchettoN, ...]: Corrisponde all'opzione “rimuovi completamente” che si sceglie dal menù a tendina che si apre quando clicchiamo col destro su uno dei programmi elencati nell'area dei pacchetti in Synaptic. Tenete a mente questo comando perchè anche se di norma usate Synaptic per installare/disinstallare potrebbe aiutarvi a sbloccare la situazione se avete problemi irrisolvibili a reinstallare un pacchetto.

apt-get -s install [nomepacchetto] : simula il processo di installazione di un pacchetto, avvisandoci degli eventuali problemi. Utile per controllare se il pacchetto che stiamo installando/aggiornando modificherà altri pacchetti da noi installati.

apt-get -f install [nomepacchetto] oppure lo stesso comando in forma estesa:

apt-get install [nomepacchetto] --fix-broken

Potreste avere bisogno di eseguirlo qualora cercando di installare un pacchetto, vi venga restituito un errore di dipendenze irrisolvibili, nonostante questo pacchetto si trovi in Synaptic.

Può succedere ad esempio, se voi aggiungete nella vostra source.list un repository nuovo che contenga delle versioni aggiornate di pacchetti che avete gia in Synaptic. Con questo comando dovreste risolvere i vostri problemi.

apt-get install [nomepacchetto] --fix missing

Se si verificano dei problemi durante l'installazione di un pacchetto e il processo di installazione si interrompe senza essere portato a termine, in pratica il pacchetto è stato scaricato nella cache ma non installato, questo comando vi permette di rimettere le cose a posto.

apt-cache search [nomeprogramma, nomepacchetto o stringa da cercare]: usando questo comando possiamo cercare pacchetti in base al nome, alla descrizione, ecc …

Questo comando esegue la ricerca della parola-chiave "nomeprogramma" all' interno delle liste dei pacchetti, inclusi i nomi dei pacchetti e le loro descrizioni. Potete usare più parole-chiave, come ad esempio "apt-cache search text editor" per ottenere una lista degli editor di testo.

apt-cache show [nomepacchetto]: questo comando visualizza una breve descrizione del pacchetto da noi richiesto, fornendo versione, uso, dimensione (utile se intendete scaricarlo da internet) un elenco dei pacchetti da cui eventualmente dipende e altre utili informazioni.

Una volta che avete trovato un programma che sembra interessante grazie a "apt-cache search", potete visualizzare informazioni dettagliate al suo riguardo usando questo comando.

apt-get clean

i pacchetti scaricati vengono memorizzati in /var/cache/apt/archive/ che col passare del tempo tende a gonfiarsi notevolmente. Con questo comando e' possibile dire all' apt-system di cancellare questi pacchetti.

Quando chiedete ad Apt di installare un nuovo programma, il relativo pacchetto viene scaricato e immagazzinato in una zona di cache sul vostro disco prima di essere installato. Se rimuovete il programma, e in seguito decidete di reinstallarlo, Apt non avrà più bisogno di scaricarlo da internet dato che è ancora presente nell' area di cache sul vostro disco. Questo meccanismo è molto utile per risparmiare banda, ma in breve tempo può occupare molto spazio su disco. Per questo è una buona idea cancellare periodicamente i vecchi pacchetti dalla cache. Notare che, se fatta a mano, questa operazione causera' un certo "disorientamento" da parte di apt convinto di avere una copia di eventuali pacchetti in locale.

Usare "apt-get clean" svuota Completamente la cache dei pacchetti, il che può a volte rappresentare un ottimo guadagno di prezioso spazio disco. Il comando è assolutamente sicuro, dato che la cosa peggiore possibile è che Apt sia costretta a scaricare nuovamente da internet un pacchetto se questo era stato rimosso e decidete di reinstallarlo.

apt-get autoclean:

Questo comando è del tutto simile al precedente, se non per il fatto che compie il suo dovere in maniera leggermete più furba: invece di ripulire l' intera cache dei pacchetti, cancella unicamente quelli sorpassati. Ad esempio, la vostra cache potrebbe contenere le ultime 3 versioni di un editor di testo che è stato aggiornato più volte: "apt-get autoclean" cancellerà le 2 più vecchie e manterrà quella più recente. Questo ha senso, dal momento che se voleste reinstallare un programma non usereste certo versioni diverse da quella più recente. Anche questo comando è estremamente sicuro per cui, se vi trovate un po' a corto di spazio su disco e non volete che la cache cresca troppo, potreste eseguirlo periodicamente. Non ci sono molte ragioni per tenere su disco versioni vecchie dei programmi.

apt-get update

Aggiorna la lista dei pacchetti disponibili nei repositories abilitati nel nostro sistema, e le informazioni riguardanti i pacchetti.

Da eseguire in special modo ogni volta che avete cambiato le "liste dei repositoires", presenti nei file della cartella /etc/apt/sources.list.d Dopo avere eseguito questo comando è probabile che nella lista dei pacchetti da scaricare ci sarà software nuovo disponibile, che prima non avevate.

E' consigliabile eseguire l'update periodicamente per essere sicuri che le proprie liste rimangano sempre aggiornate.

apt-get upgrade: aggiorna i pacchetti installati sul nostro sistema (se sono disponibili versioni piu' recenti). Con il passare del tempo, la maggior parte del software che avete installato diventerà obsoleto con il rilascio di nuove versioni che aggiungono funzionalità o correggono errori. E' sufficiente digitare "apt-get upgrade" per fare in modo che Apt controlli se esiste una nuova versione per ogni singolo pacchetto presente nel vostro sistema, la scarichi e la installi.

È anche possibile aggiornare un singolo pacchetto attraverso l'esecuzione del comando:

apt-get upgrade nomepacchetto

apt-get dist-upgrade: e' simile a apt-get upgrade, ma aggiorna anche scripts di configurazione, ecc ...

Può capitare che esista una nuova versione per un programma che avete già installato ma che, per poter funzionare e rendere disponibili tutte quelle nuove funzionalità che vi interessano, richieda nuove dipendenze. Ad esempio potreste aver installato un player multimediale che supporta diversi formati. Man mano che nuovi formati vengono rilasciati, i moduli ad essi relativi potrebbero essere disponibili tramite pacchetti aggiuntivi: per questo motivo la più recente versione del vostro player preferito potrebbe dipendere da questi pacchetti, che non sono però installati nel vostro sistema. Se lanciate semplicemente "apt-get upgrade", otterrete l' aggiornamento del player, ma nessuno dei nuovi pacchetti contenenti i nuovi formati. Il comando "apt-get dist-upgrade" rimedia a questo problema: non soltanto aggiorna tutti i pacchetti installati alla versione più recente (come fa "apt-get upgrade"), ma installa anche tutte le dipendenze aggiornate e che non erano presenti sulla vostra macchina. Se volete che il vostro sistema sia sempre aggiornato all' ultima versione e con tutte le correzioni relative alla sicurezza disponibili, la miglior strada possibile è quella di lanciare "apt-get update" e "apt-get dist-upgrade" di tanto in tanto.

apt-get check

controlla che nel computer non ci siano dipendenze “rotte”, non soddisfatte.

apt-get autoremove

è usato per rimuovere pacchetti che erano stati installati in automatico dal sistema per soddisfare le dipendenze di determinati programmi ma che ora non sono più necessari. E' un comando da usare con un po' di cautela

Gestori/installatori di pacchetti presenti localmente nel filesystem

Installare pacchetti ricavati per vie alternative ai repository e scaricati o copiati nel filesystem.

Scaricando i programmi da Internet, o ricavandoli dai CD di qualche rivista, oltre al software distribuito in forma di pacchetti .deb, .rmp, .tgz, i programmi possono venire forniti in forma di pacchetti .run o .bin (GoogleEarth, per esempio, in genere è distribuito in questo modo). Si tratta di software precompilati, con integrate le librerie di cui necessitano. Si presentano in formato binario non compresso pronti per essere eseguiti, tipo i "setup.exe" di Windows. Più spesso troviamo sorgenti compressi con estensione .tar.gz, .tgz, tar.bz2 e .tbz2 che, in gergo, sono chiamati tarball o file zip. Caso particolare poi sono i sorgenti che possiamo ottenere direttamente dai repository della nostra distribuzione. Vedremo a grandi linee come comportarci e come installare queste varie tipologie di software.

Naturalmente il modo più sicuro per mantenere il proprio sistema stabile è quello di utilizzare i repository ufficiali della propria distribuzione, dove il software viene testato e mantenuto aggiornato. Ricorrere ad altre fonti deve essere fatto con cautela o sapendo quello che si sta facendo. Vi è una forte interrelazione tra i programmi poichè spesso utilizzano librerie in comune; introdurre nel sistema files non coerenti può generare conflitti non sempre facilmente risolvibili, meno che mai da principianti non ancora sufficientemente smaliziati con questo sistema operativo.

Per questo motivo il metodo d'elezione per introdurre software deve essere attraverso l'uso di Synaptic, utilizzando i repository ufficiali previsti dalla distribuzione. Sarebbe meglio usare Apt che ne rappresenta “il motore”, ma funzionando a riga di comando di solito non è gradito ai novizi, tuttavia conviene prenderci, nel tempo, un po' di confidenza perchè potrebbe capitare che Synaptic incorra in problemi e si debba ricorrere ad Apt per sbloccarlo.

Quando si voglia installare pacchetti debian (.deb) ottenuti per vie diverse da Sinaptic/Apt, si userà preferibilmente Gdebi (con interfaccia grafica) o Dpkg (a riga di comando). Attenzione però, il fatto che si tratti di un pacchetto .deb, non ci garantisce che funzionerà a dovere. Se era stato sviluppato prendendo in considerazione, ad esempio, il ramo “debian testing” potrebbe aver bisogno di librerie che per il nostro ramo (debian stabile) non sono disponibili o lo sono in versioni inadatte. Ad ogni modo un pacchetto .deb che non dovesse funzionare si potrà sempre eliminare completamente senza lasciare tracce.

I pacchetti .run o .bin sono in genere sicuri perchè avendo le librerie integrate se le portano dietro anche all'atto di una eventuale disinstallazione. Con i sorgenti invece, a parte quelli derivanti dai repository della propria distribuzione, c'è sempre il rischio di introdurre files incoerenti che potrebbero rimanere nel sistema anche nel caso di una successiva disinstallazione.

ATTENZIONE

Installare questo tipo di software può compromettere la sicurezza dell'intero sistema, non essendo controllati ed essendo necessari i privilegi di amministrazione.

Si ricordi che per il software non presente nei repository, nessun controllo è effettuato dal sistema sulla loro autenticità e su eventuali falle di sicurezza introdotte, come invece per il software installato tramite Apt. Quindi bisogna accertarsi della loro provenienza e che siano autentici, prima di procedere alla loro installazione. In ogni caso il software installato in questo modo non sarà aggiornato automaticamente da Apt, l'unico vantaggio sarà nel permetterne la rimozione sicura con gli strumenti del sistema. L'utente che ha installato il pacchetto dovrà occuparsi di controllare l'esistenza di aggiornamenti, e poi installarli.

Quando si vuole utilizzare software sotto forma di pacchetti precompilati, occorre fare attenzione alla piattaforma. Infatti, non basta che si tratti di programmi compilati per il proprio sistema operativo, occorre che gli eseguibili siano adatti anche al tipo di elaboratore su cui il sistema operativo è in funzione.

Normalmente, per identificare l'architettura dei «PC» (x86), si utilizza la sigla i386 presente nel nome del file del programma scaricato, oppure negli archivi da cui è stato fatto il download. Sigle come i486, i586, i686,... rappresentano la stessa architettura basata però su un livello particolare del microprocessore.

Potrebbe esservi utile sapere che l'architettura del vostro processore è ricavabile dal comando:

$ uname -m

SCHEMA RIASSUNTIVO INSTALLAZIONE TIPOLOGIE DI SOFTWARE

I formati principali del software che potreste trovare da installare a livello locale sono i seguenti:

• .deb
• .rpm
• .tar.gz
• .tar.bz2
• .sh
• .run
• .bin
• .package
• .py

Vediamo in maniera riassuntiva come vanno installati uno per uno, poi prenderemo in esame in maniera più completa i vari strumenti d'installazione che abbiamo chiamato in causa, analizzando eventuali problematiche e comandi aggiuntivi.

Pacchetti .deb

Tra le tipologie viste sopra, il formato .deb è quello che si trova più frequentemente. Per installare questi pacchetti si può utilizzare il programma ad interfaccia grafica Gdebi che fa tutto in automatico.

Si può utilizzare Gdebi anche via terminale così:

# gdebi nomepacchetto.deb

Il pacchetto così installato può essere disinstallato utilizzando Synaptic o Apt.

Oppure da terminale si può utilizzare Dpkg
Aprire il terminale e digitare
# dpkg -i nomepacchetto.deb

questo comando aggiunge un pacchetto che potrebbe avere dipendenze non soddisfatte, per evitare questo problema conviene dare subito dopo questo comando di Apt:

# apt-get -f install

Per effettuare la disinstallazione possiamo utilizzare la modalità grafica con Apt, Synaptic o Gdebi o il terminale con il comando:# dpkg -r pacchetto.deb

Pacchetti .rpm

Alcune distribuzioni Linux usano il sistema di pacchettizzazione RPM (abbreviazione di RedHat Package Manager).

Questi pacchetti .rpm sono simili a pacchetti .deb per molti aspetti ma non possono essere utilizzati così come sono dai sistemi di gestione del software di antiX MX, ma vi è un programma a riga di comando, chiamato Alien, in grado di convertire i pacchetti .rpm in pacchetti .deb.

Accertiamoci che sia installato il pacchetto alien, poi si darà questo comando:

# alien -d nomepacchetto.rpm

In questo modo verrà posizionato un file .deb con lo stesso nome, e nella stessa posizione, del file .rpm che a questo punto sarà possibile installare con Gdebi.

ATTENZIONE Qualora sia necessario disporre di un programma non presente nei repository, si hanno meno probabilità di rendere instabile il sistema utilizzando sorgenti piuttosto che .rpm convertiti con Alien.

File .tar.gz e .tar.bz2

Si tratta di “sorgenti” presenti in forma di archivi compressi.
Prima di tutto accertiamoci che siano installati i pacchetti checkinstall e build-essential.
Quindi diamo i seguenti comandi dal terminale:
# apt-get install build-essential
# apt-get install checkinstall
Fatto questo bisogna scompattare gli archivi dei sorgenti con il comando:
$ tar zxvf pacchetto.tar.gz
per gli archivi con estensione .tar.bz2 invece:
$ tar jxvf pacchetto.tar.bz2
Dopo aver scompattato l'archivio, bisogna entrare nella cartella che il processo di estrazione ha creato e cercare eventuali file readme o install che vi illustreranno eventuali procedure di installazione.
Qui riportiamo i classici comandi per la compilazione e l’installazione di sorgenti:
Spostiamoci nella cartella scompattata con il comando:
cd cartellapacchetto
E lanciamo in sequenza questi comandi:
$ ./configure
$ make
# checkinstall
L’ultimo comando checkinstall permette di trasformare il file .tar in un pacchetto .deb, azione che facilita eventuali aggiornamenti o rimozione del software.
Per un analisi più approfondita delle varianti e possibili problematiche vedere l'apposito paragrafo, più avanti, sulla compilazione dei sorgenti.

File .sh .run .bin .package .py

Prima di cominciare diamo i permessi di esecuzione ai file che vogliamo installare con questi comandi:
$ chmod u+x programma.sh (o chmod u+x programma.run/bin/package)
Ora digitiamo sempre da terminale, con i privilegi di root:# ./programma.sh

…oppure

./programma.run/bin/package

Il software scritto in linguaggio python si presenta con l'estensione .py.

Anche in questo caso al file vanno dati i permessi di esecuzione:

$ chmod u+x programma.py

poi si darà questo comando:

$ python programma.py

                                                     DPKG                                                                  

Installazione di pacchetti .deb con Dpkg

1. Aprire il terminale, diventare root usando il comando su e inserire la password di root quando richiesto.
2. Utilizzare il comando cd per passare alla directory contenente il tuo file .deb che hai scaricato.

3. Installare il pacchetto con il comando (ovviamente sostituendo nomepacchetto con il vero nome del pacchetto):

dpkg --install nomepacchetto.deb

Al posto di --install è possibile usare -i

dpkg -i nomepacchetto.deb

Se si vuole installare più pacchetti contemporaneamente, si può fare tutto in una volta sola usando:

dpkg -i *.deb

NOTA: Nei comandi da usare con la shell, l'asterisco è una specie di carta jolly. In questo caso, farà sì che il programma applichi il comando ad ogni file il cui nome termina con ".deb".

4. Se le dipendenze necessarie non sono già installate sul vostro sistema, si ottengono errori di dipendenze insoddisfatte dato che dpkg non può recuperarle/scaricarle autonomamente. Per correggere questi errori e quindi completare l'installazione, eseguire

apt-get -f install

Apt tenterà di correggere la situazione, installando le necessarie dipendenze (se sono disponibili nei repository), o rimuovendo i file .deb (se le dipendenze non possono essere installate).

5. La disinstallazione è altrettanto semplice:

dpkg -r nomepacchetto.

Ad esempio dpkg -r scribus.

Anche in questo caso è possibile usare --remove al posto di -r.

Questo comando rimuove unicamente i binari (il programma stesso) ed i relativi script di avvio, ma non cancella nessuno degli eventuali file di configurazione. Reinstallando il programma in un secondo momento, verranno quindi usati i file di configurazione esistenti, risparmiandovi di doverli ricreare da zero. La disinstallazione di un pacchetto richiede che nessun' altro pacchetto dipenda da quello che vogliamo rimuovere, nel qual caso dovremo prima rimuovere quelli da esso dipendenti.

È importante però precisare che il comando precedente elimina il software ma non i suoi file di configurazione, quindi, per la rimozione completa del programma è necessario utilizzare

dpkg --purge nomepacchetto

Es. dpkg -purge kaffeine.

Questo comando si occupa di rimuovere qualsiasi cosa legata al programma: binari, script di avvio, file di configurazione, tutto. Il purging di un programma richiede che nessun' altro pacchetto dipenda da quello che vogliamo rimuovere, nel qual caso dovremo prima rimuovere quelli da esso dipendenti. Se fate il purging di un programma ed in seguito decidete di reinstallarlo, dovrete riconfigurarlo da capo dato che i file di configurazione sono stati rimossi insieme ai binari.

Per ottenere informazioni su un pacchetto il comando da eseguire è

dpkg -I nomepacchetto,

come nel caso di dpkg -I inkscape.

Per avere l'elenco di tutti i pacchetti installati:

dpkg --list

Digitano ad esmpio:

dpkg --list | grep gnome

otterrò l'elenco di tutti i pacchetti "gnome" installati.

Invece questo comando:

dpkg -L nomepacchetto

Elenca tutti i files relativi al pacchetto installato. Se avete appena installato qualcosa e non sapete dove sia stato posizionato, usate questo comando per scoprirlo.

Il comando:

dpkg -S filemaisentito

Trova il pacchetto che contiene il file "filemaisentito". Molto utile se avete un file sul disco ma non avete idea da dove sia saltato fuori!

Ad esempio se voglio sapere a quale pacchetto appartiene il file “amarok_proxy.rb”, digitando:

“dpkg -S amarok_proxy.rb”, avrò come risultato che appartiene al pacchetto “amarok-common”.

Può essere utile anche interrogare dpkg con questo comando quando si veda un file sospetto in directory importanti come /bin o /usr/bin.

GDEBI

Installazione di pacchetti .deb con Gdebi

Gdebi è un'applicazione per l'installazione, gestione e configurazione di pacchetti .deb. Si tratta di un programma di utilità in esecuzione in modalità grafica o da terminale che permette l'installazione di pacchetti al di fuori dei repository APT: da un sito web, CD-ROM, supporto mobile, etc.

Consente di installare pacchetti deb locali risolvendo e installando le loro dipendenze. Assicura che il pacchetto da installare sia compatibile con la versione e l'architettura del sistema su cui si tenta di installare, ed assicura anche che tutte le dipendenze richieste dal pacchetto siano soddisfatte. In caso contrario, le dipendenze vengono scaricate, via Internet, dai repository di APT. Nel qual caso ovviamente si dovrà disporre di una connessione Internet configurata e attivata.

Installazione di un pacchetto .deb con Gdebi in modalità grafica

L'utilizzo è intuitivo e in genere, una volta che il file .deb viene scaricato, è sufficiente cliccare su un pacchetto .deb per effettuarne l'installazione.

Oppure cliccate col destro sul pacchetto da installare, quindi dal menù a discesa selezionate l'opzione "Apri con Installatore Pacchetto Gdebi".

Nella finestra di apertura di Gdebi, cliccare sul pulsante "Installa Pacchetto".

GDebi controlla automaticamente che le dipendenze necessarie per l'installazione del pacchetto siano soddisfatte e, se necessario, viene chiesta l'approvazione ad installare i pacchetti aggiuntivi necessari. Le dipendenze, vengono scaricate dai repository di APT.

Una volta che il pacchetto o pacchetti sono stati installati, questi saranno presenti nel database di Apt.

Ciò permette di poterli eventualmente disinstallare facilmente utilizzando Synaptic o Apt.

Disinstallare un pacchetto .deb

Per poter disinstallare un pacchetto .deb, utilizzando Gdebi, si dovrebbe avere mantenuto il file .deb. Cliccare col destro sul file .deb in questione e nel menu a discesa che compare selezionare "Apri con Installatore Pacchetto Gdebi".

Nella finestra di Gdebi, appaiono due pulsanti. "Reinstalla pacchetto" e "Rimuovi pacchetto." Fare clic su "Rimuovi pacchetto".

Aggiornamento di un pacchetto .deb

Una volta che un pacchetto è stato installato con Gdebi, questo viene registrato da Apt (e quindi Synaptic) negli elenchi dei pacchetti presenti nel sistema, tuttavia si tratta di un pacchetto presente in locale e non negli archivi dei repository elencati nel file /etc/source.list perciò Apt non sarà in grado di accorgersi quando il programma è disponibile in una versione aggiornata. Questi pacchetti però possono essere aggiornati utilizzando Gdebi, a patto che ci si interessi di persona di monitorare quando è disponibile una versione aggiornata. Vediamo come:

Scaricate la nuova versione del pacchetto .deb da aggiornare.

Cliccate col destro sul file .deb scaricato e selezionare il menu "Apri con Installatore Pacchetto Gdebi".

Nella finestra di Gdebi, fate clic sul pulsante "Aggiorna pacchetto"

Utilizzare Gdebi da terminale

In un terminale, digitare il seguente comando:

$ su [invio] password [invio]

# gdebi nomepacchetto.deb

Ed è possibile effettuare un'installazione simulata, per controllare le operazioni che saranno eseguite con APT, con:

$ gdebi --apt-line nomepacchetto.deb

Se tutte le dipendenze sono state soddisfatte e ancora risultino errori è possibile che la versione di una qualche dipendenza non sia quella richiesta.

Volendo insistere, si può cercare di installarlo con il comando:

# apt-get --fix-broken install [nomepacchetto] (o la forma contratta apt-get -f install [nomepacchetto])

Se è possibile, APT cercherà di risolvere i problemi, se non ci riesce, eliminerà il pacchetto (dopo avercene chiesto conferma).

ALIEN
Convertire e installare i pacchetti RPM
Alcune distribuzioni Linux usano il sistema di pacchettizzazione RPM (abbreviazione di RedHat Package Manager, sviluppato dalla distribuzione RedHat Linux. I pacchetti .rpm sono simili a pacchetti .deb per molti aspetti, e vi è un programma a riga di comando, chiamato Alien, in grado di convertire i pacchetti .rpm nei .deb utilizzati da antiX MX.
Alien dovrebbe essere già pre installato in MX Linux, se non lo fosse è disponibile nei repository:
apt-get install alien
Alien può essere utilizzato per installare un pacchetto .rpm, con questi comandi:
$ su [invio] password [invio] per diventare amministratori.
Poi,con il comando cd, ci portiamo nella cartella dove abbiamo messo il programma
cd /percorso/della cartella
infine il comando che ci interessa:
# alien --to-deb nomepacchetto.rpm

Lo stesso comando può essere digitato in forma semplificata così:

# alien -d nomepacchetto.rpm

In questo modo verrà posizionato un file .deb con lo stesso nome, e nella stessa posizione, del file .rpm che a questo punto sarà possibile installare con Gdebi.
Va detto che le distribuzioni Debian e Debian-derivate hanno nei propri archivi più di 45.000 pacchetti per ramo/architettura, risulta difficile perciò che vi sia la necessità di convertire qualche pacchetto RPM in Debian. Qualora sia necessario disporre di un programma non presente nei repository, si hanno meno probabilità di rendere instabile il sistema utilizzando sorgenti piuttosto che .rpm convertiti con Alien.

Installare programmi con formati di tipo: .bin .run .sh .package .py

Spesso si reperiscono programmi sotto forma di pacchetti .run o .bin. Si tratta di software precompilati, di solito con le librerie di cui necessitano già integrate. Per il software distribuito in questo modo, non è necessaria alcuna compilazione (prevista invece per i sorgenti), è sufficiente eseguirli dalla shell o in alcuni casi tramite un semplice doppio clic sul file, dopo di che in genere il processo si completa seguendo procedure guidate grafiche o testuali.

Supponiamo di disporre del file “nomesoftware.bin” o “nomesoftware.run” (la procedura è identica in entrambi i casi).

Solitamente quando questi pacchetti vengono scaricati da internet, gli attributi di questi files vengono settati a “non eseguibile”. Per prima cosa, bisogna rendere il file eseguibile . Per farlo basta cliccare con il tasto destro sul file->proprietà->permessi e mettere il segno di spunta su: “Permetti di eseguire il file come un programma”, poi di fianco a “proprietario” sulla stessa finestra controllare che sia selezionata l'opzione “lettura e scrittura”.

In alternativa col terminale portatevi nella directory dove avete scaricato il programma con il comando cd e successivamente date il seguente comando:

$ chmod u+x nomesoftware.run

A questo punto, in alcuni casi è sufficiente avviare il programma con il comando

$ ./nomesoftware.run

Qualche volta però, il programma prevede un'installazione vera e propria, con necessità di scrivere e creare link in cartelle di sistema protette in scrittura, dove solo l'amministratore ha questi privilegi. Quindi per permettere al software di installarsi e scrivere quello che gli pare nei files di sistema, dovremo dare il comando precedente in qualità di root:

$ su ([invio] password di root [invio])

# ./nomesoftware.run

ed seguire le istruzioni che compariranno sullo schermo.

E' evidente che se avevo agito sui permessi in modalità grafica, prima di dare il comando soprastante, devo portare il terminale nella cartella dove ho messo il programma, usando il solito comando cd.

In teoria si potrebbe utilizzare la modalità grafica, anche per l'ultimo passaggio andando nel MenuStart, in alto dove c'è la tringa vuota di ricerca, si dovrebbe scrivere:

/percorso/nomeprogramma.run

Ma qualora sia necessario avere i privilegi di root, si dovrebbe effettuare questa operazione all'interno di una sessione di root, il che non è pratico e non ha molto senso.

I comandi che abbiamo visto valgono anche per alcuni pacchetti .sh e il formato .package.

In quest'ultimo caso, la procedura si differenzia solo per il fatto che, una volta avviata l'installazione, lo script verifica il contenuto del pacchetto e la presenza nel sistema di alcuni software indispensabili (le cosiddette dipendenze) prima di procedere con l'installazione del programma.

In caso contrario, scarica da internet e installa automaticamente tutti quelli mancanti (è solo necessario essere connessi alla rete).

Oltre a questi formati esistono altri sistemi di distribuzione del software, sempre tramite software precompilato.

Ad esempio, software come Opera, Firefox, Thunderbird, e molti altri, sono disponibili sotto forma di archivi compressi contenenti il software già compilato. Spesso non è neppure necessaria una vera e propria installazione: basterà scompattarli e poi eseguire un file. In genere, il file da eseguire si presenta senza estensione, con lo stesso nome del programma. Nel caso di Thunderbird, si tratta dello script:

thunderbird

La maggior parte di questi pacchetti compressi sono archivi “tar” che vedremo nel prossimo paragrafo come scompattare; se si trattasse (raramente) di un archivio “rar” per decomprimerlo bisognerà prima scaricare attraverso Apt/Synaptic il pacchetto “rar”.

Un ulteriore caso è quello del software scritto in linguaggio Python. Si tratta di script riconoscibili perchè si presentano cosi:

nomesoftware.py

Anche in questo caso il file in questione andrà reso eseguibile secondo le modalità (grafica o da terminale) viste in precedenza e poi aperto il terminale si darà questo comando:

$ python /percorso/nomesoftware.py

Perché bisogna inserire ./ prima del nome per eseguire alcuni programmi?

Ogni volta che si esegue un comando dalla shell, a meno che non si indichi il percorso completo dove questo è posizionato all'interno del file system, il sistema effettua una veloce ricerca per individuarlo. Tale ricerca prende in considerazione tutte le directory contenute nella variabile di ambiente PATH (per visualizzarne il contenuto basta eseguire il comando echo $PATH). È ovvio che, nel momento in cui l'eseguibile non è presente in nessuna delle directory contenute in PATH, il comando non può essere avviato. In questo caso, per eseguire il programma i metodi sono due. Il primo, come abbiamo detto, consiste nell'indicare il percorso completo, ad esempio per eseguire il programma prova, presente, ad esempio, nella nostra home, il comando diventa /home/nome_utente/prova. Il secondo metodo consiste nell'accedere alla directory che contiene il programma (in questo caso cd /home/nome_utente) ed eseguirlo con ./prova. In pratica, in quest'ultimo caso, non essendo il programma contenuto nei percorsi contenuti nella variabile PATH, è stato necessario indicare che si trova nella directory corrente, cioè quella in cui ci troviamo. Infatti, il . (punto) serve per indicare al sistema di cercare l'eseguibile nella directory corrente mentre il simbolo / completa il percorso. È comunque possibile evitare di inserire ogni volta i caratteri ./, indicando la direcory corrente nella variabile PATH:

PATH=.:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin

export PATH

In questo modo abbiamo aggiunto anche la directory corrente tra i percorsi degli eseguibili, quindi possiamo avviare qualsiasi programma, da qualunque posizione senza inserire ./ prima del nome, ma solo se questo è presente nella directory in cui ci troviamo.

                                       SORGENTI                                     

Compilare e installare sorgenti

Qualsiasi programma open-source può essere compilato dal codice sorgente utilizzato dal programmatore, se non c'è altra scelta.

Questo codice non è altro che un semplice file di testo, mentre il computer esegue files che non hanno nulla di testuale, e che comprende soltanto lui: i cosiddetti files “binari”. Hanno questo nome perchè il loro codice si esprime utilizzando sequenze di due numeri :“0” e ”1” . L'operazione di compilazione permette di ottenere dai sorgenti il file binario funzionante nella macchina e quindi “eseguibile”.

Una sorta di “traduzione” necessaria, perchè se il processore è in grado di riconoscere solo questo tipo di sequenze, per un programmatore sarebbe invece molto difficile, per non dire impossibile, elaborare il software direttamente in questo linguaggio.

Il compilatore è lo strumento che compie questa “traduzione”. Ogni compilatore realizza binari a partire da files testuali scritti nel linguaggio di programmazione che esso comprende. Quindi per compilare un programma in C, avrai bisogno del compilatore C, mentre per compilare un programma in Fortran avrai bisogno del compilatore Fortran, perciò per installare un programma da sorgenti, devi avere il compilatore adatto.

In genere viene usato il linguaggio C, C+ o C++ compilabile con GCC, ma ne esistono tanti altri. Mepis installa di default i compilatori per i principali linguaggi di programmazione, ma se dovesse mancare per un particolare programma verrà richiesto all'atto della compilazione come una “dipendenza” da soddisfare.

Il neofita potrebbe pensare che doversi confrontare (anche se raramente o addirittura mai) con la compilazione dei sorgenti, nei sistemi unix, sia una complicazione rispetto ai sistemi operativi commerciali in cui i programmi si trovano in forma binaria pronti da installare. In realtà non si tratta di un difetto ma di una grande risorsa che sta alla base della forza di GNU/Linux. L'assenza dei sorgenti nei programmi commerciali deriva dalla volontà da parte delle case produttrici di nascondere il software: se si potesse vedere come è realizzato un certo programma, facilmente si sarebbe in grado di superare le varie protezioni per cui poi potrebbe non essere più necessario acquistarne altre copie o gli aggiornamenti.

Il S.O. GNU/Linux d'altro canto, aderisce alla filosofia del progetto GNU, che prevede che il software, compreso il Kernel, venga reso disponibile insieme ai sorgenti lasciando libera la possibilità di modificarlo, secondo quanto previsto dalle licenze GPL.

I sorgenti di solito sono distribuiti come files con estensione .tar.gz, .tgz, tar.bz2 e .tbz2 che, in gergo, sono chiamati tarball.

Un tarball, in pratica, è un archivio che ha subito un doppio processo di archiviazione/compressione. I file vengono per prima cosa archiviati come un unico file con il programma tar, per poi essere compressi con Gzip o Bzip2.

Per prima cosa è necessario decomprimere i files. Si può procedere graficamente, spostando il tarball nella cartella dove lo vogliamo conservare (consiglio /home/nomeutente creandoci dentro una cartella apposita ad es. “sorgenti” o in /usr/src) dopo di che cliccandoci sopra col destro si selezionerà dal menù a discesa estrai-> estrai qui.

Se nel menù a discesa mi compare “estrai”, ma non “estrai in”, vuol dire che il tarball è in sola lettura, quindi sempre cliccando col destro sceglieremo “proprietà” e poi nella finestra “permessi” selezioneremo in “proprietario”:lettura e scrittura.

In alternativa si può aprire il programma di compressione/decompressione andando in MenuStart → Accessori → File → Gestore di Archivi. Anche in questo caso, per il proprietario che dobbiamo essere noi, il file deve essere “leggibile e scrivibile”.

Come ulteriore possibilità lo si può decomprimere utilizzando il terminale. Spostatevi con questo nella cartella dove avete posizionato il sorgente, utilizzando il comando cd,

dopo di chè digitate uno dei seguenti tre comandi:

$ tar -xzvf nomeprogramma-1.1.0.tgz

oppure:

$ tar -xjvf nomeprogramma-1.1.0.tar.bz2

o ancora

$ tar -xvf nomeprogramma-1.1.0.tar.bz2 --bzip2

Usate il primo comando con i file compressi con Gzip (quindi quelli con estensione .tar.gz o .tgz), mentre il secondo e il terzo (equivalenti) sono da usare con i file compressi con Bzip2 (con estensione .tar.bz2 o .tbz2).

Vediamo a che servono i parametri (per ulteriori informazioni sul comando tar digitate “man tar”):

-x estrae l'archivio;

-z scompatta gli archivi .gz;

-j scompatta gli archivi .bz2;

-v (verbose) visualizza la lista dei file presenti nell'archivio;

-f fa compiere l'operazione sul successivo file da noi specificato.

Per un principiante sarà più veloce usare la modalità grafica che abbiamo visto, ma in qualche caso potrebbe essere più pratico utilizzare il terminale e la conseguente modalità testuale, ad esempio dovendo decomprimere molti archivi tutti in una volta farà comodo usare questo comando:

$ find -name "*.tar" -exec tar xvf {}

dove “find” cerca tutti files che finiscono per .tar (-name "*.tar") e per ognuno di questi ({}) esegue (-exec) il tar xvf

Una volta scompattato viene creata una directory con lo stesso nome dell'archivio (naturalmente senza l'estensione). Tale directory è più o meno articolata in sottodirectory, dove nella cartella principale in genere si trovano:

• uno o più file di documentazione (README, INSTALL, ecc.)
  
• uno o più script preparati per facilitare la compilazione, come il file “configure”
  
• il file “ makefile” (o file-make)
  

Vi puo essere anche una cartella denominata “src”, e/o una “test”, se la prima è presente allora i file di codice sorgente saranno là dentro, la presenza della seconda ci dirà che sarà possibile effettuare dei test a fine compilazione per verificare il corretto funzionamento del software, prima di installarlo.

Questa impostazione è quella canonica, ma una consistente percentuale di sorgenti non la rispetta. Dipende se il programmatore ha realizzato il software aderendo allo standard Gnu o meno, oppure dal tipo di programma utilizzato per svilupparlo.

Comunque vi è sempre la presenza di un file README, molto spesso anche di un INSTALL, mentre può non comparire il file “configure”; a volte non è presente nemmeno il “makefile”, più raramente non ci saranno tutti e due (come nel software realizzato in Python).

E' assolutamente indispensabile leggere con attenzione README ed INSTALL (sono scritti in un Inglese molto semplice, che eventuali traduttori come “google translate” o “yahoo babel fish” rendono comprensibile a tutti), perchè ci informano riguardo le dipendenze necessarie e sull'esatta procedura di installazione, soprattutto qualora questa richieda passaggi non canonici, cosa che accade con una certa frequenza.

La maggior parte delle volte i pacchetti tar.gz o tar.bz2 prevedono le modalità di compilazione e installazione che stiamo per spiegare, ma ci sono delle eccezioni che prevedono delle procedure peculiari che potrete scoprire solo leggendo la documentazione.

Leggendoli capirete anche se i pacchetti tar.gz scaricati sono davvero sorgenti o i binari compressi di cui si era accennato alla fine del paragrafo precedente. Sembrerà banale, ma non è scontato che un principiante non si confonda su queste cose.

Prenderemo in considerazione prima un sorgente più o meno tipico e poi vedremo cosa fare di fronte ad alcune eccezioni.

Decompresso il tarball, il passaggio successivo è costituito dalla compilazione del sorgente, dopo di che si avranno 2 possibilità: o installare il binario così ottenuto o creare un pacchetto .deb da installare.

Quest'ultimo, a differenza del “binario semplice pronto da installare”, si potrà disinstallare senza problemi ed eventualmente reinstallare con facilità.

La procedura che per comodità abbiamo chiamato “binario semplice pronto da installare” è la procedura classica che però è decisamente sconsigliata mentre la seconda è più sofisticata e meno pericolosa ai fini della stabilità, crea pacchetti .deb, ma non secondo la procedura Debian e potranno funzionare solo sul computer che li ha prodotti.

Per ciò che riguarda la creazione dei pacchetti secondo procedura Debian, mostreremo un modo semplificato adatto alla creazione di pacchetti ad “uso personale” (che potranno in realtà funzionare anche su altri computer con la stessa architettura), ma che non potrebbero essere distribuiti ad altri perchè non conterranno tutte le informazioni previste dallo standard Debian) poi daremo indicazioni nel caso particolare che il pacchetto .deb lo si voglia ottenere scaricando un sorgente dai repository della distribuzione.

Faccio presente che ci sono svariati altri modi di gestire i sorgenti. Si tratta di una materia che presenta una certa complessità e delicatezza quindi non adatta ai neofiti, che infatti devono cercare di evitarne l'uso, magari ricercando delle soluzioni alternative. Tuttavia è bene averne una conoscenza almeno a grandi linee. In ogni caso ad un principiante che volesse installare un sorgente complesso o un sorgente di cui non è sicuro della fonte, di cui non sa se crea problemi o meno o che voglia sperimentare imparando a compilare dei sorgenti, consiglio di lavorare su una macchina virtuale. Un buon programma di virtualizzazione è Virtualbox su cui ci si può installare l'ISO del proprio sistema ottenuta con MX Snapshot. Si può provare a compilare in virtuale, vedere cosa succede e solo dopo fare lo stesso sul proprio sistema reale.

Qui proporremo delle metodiche che non saranno le più ortodosse bensì quelle che ci sembrano più facili e veloci da comprendere e seguire.

Anche in questo caso, come in altre parti di questa guida, prevederemo delle operazioni da fare in modalità grafica ed altre con l'uso del terminale. Si tratta di una scelta derivata dal target di utenti a cui è indirizzato questo documento, poiché il principiante che si accinge a compiere operazioni che non conosce, si sente sollevato ogni qual volta può uscire dalla modalità testuale, diversamente da chi ha confidenza con Gnu/Linux e la consolle, che giustamente considera questo andirivieni, dentro e fuori dal terminale, solo un inutile perdita di tempo.

Compilazione

E' necessario spostarsi con il terminale nella nuova directory, creata con la decompressione del pacchetto, entrandoci con il solito comando cd (change directory) :

$ cd /percorso/directory-nomeprogramma1.1.0

Ora finalmente daremo i comandi per la compilazione del programma

$ ./configure

$ make

Nella fase di configurazione (./configure) viene lanciato uno script che si occupa di verificare la presenza nel sistema di tutti i componenti (librerie + software vario, cioè le cosiddette dipendenze) necessari al funzionamento dell’applicazione.

Le dipendenze mancanti non verranno installate in automatico dal sistema, ma dovrà occuparsene l'utente. In sostanza, una volta capito cosa manca, dovremmo installarlo tramite Apt/Synaptic. Quando sarà presente tutto il necessario si potrà procedere con la successiva fase di “make” alla vera e propria compilazione dei sorgenti.

La mancanza (o una errata versione) di librerie o del compilatore, ci viene segnalata dal comando “./configure” attraverso messaggi di errore. Se questo accade leggete attentamente le ultime righe dell'output; installate (o aggiornate) i pacchetti indicati e poi ripetete la procedura, fino a quando il processo di configurazione non termina senza presentare errori, dopodiché si potrà proseguire con make.

Quando il sistema avrà verificato la presenza di tutti i files richiesti verrà generato il “makefile”: un file contenente indicazioni sulle variabili settate in questa fase (come il percorso dei link alle librerie necessarie alla compilazione, l'indicazione delle cartelle dove verranno installati i files del programma, ecc.) e altre varie istruzioni per il successivo comando che digiterete, "make". Se le dipendenze non sono tutte presenti non avrete il makefile per continuare l'installazione.

I due comandi visti, sono quelli indicati per una generica procedura di compilazione, ma ad onor del vero, prima di digitare ./configure, sarebbe opportuno dare il comando

$ ./configure --help

che permette di visualizzare le opzioni messe a disposizione dal programma per poterne attivare ( o disattivare) funzionalità particolari, in genere ben descritte nei file Readme o Install. Si potrà anche verificare se è prevista la funzione “ ./configure --prefix=percorso/di localizzazione/della cartella/di installazione” che ci potrebbe permettere di non installare, nelle fasi successive, i vari files di configurazione nelle cartelle di sistema bensì in quelle di pertinenza dell'utente.

Vediamo di spiegarci meglio.

Generalmente la cartella predefinita per l'installazione dei sorgenti è /usr/local, nel senso che i file di installazione si distribuiranno nelle varie sottocartelle all'interno di questa directory. Quindi gli eseguibili andranno in /usr/local/bin, le librerie in /usr/local/lib, e così via. In qualche caso il programmatore può prevedere come cartella di installazione /opt. Non tutte le distribuzioni Linux dispongono di questa cartella, perciò se non dovesse essere presente, o la si crea (con i privilegi di amministratori) o si darà indicazione a “./configure” di prevedere l'installazione in /usr/local in questo modo:

$ ./configure --prefix=/usr/local

Se il sistema ha previsto /usr/local o invece /opt come cartella di installazione, ci verrà segnalato proprio attraverso il comando “./configure --help”. Bisognerà poi ricordarsi, in fase di disinstallazione, di indicare la cartella che avevamo voluto con --prefix= altrimenti il programma di disinstallazione andrà a cercare i file da cancellare dove non potrà trovare alcunchè. Nell'apposito paragrafo vedremo come fare.

Ad ogni modo MX possiede la cartella /opt, perciò questo particolare problema non si pone.

Potrebbe invece capitare di voler installare il programma nella propria home, magari perchè non si è amministratori del sistema e non si conosce la password di root, o perchè non si vuole che il programma sia disponibile anche agli eventuali altri utenti del computer. Potrei allora creare una cartella apposita e poi far installare i sorgenti con il comando che abbiamo visto:

$ ./configure -–prefix=/Home/utente/CartellaAppositaPerIlMioSorgente

Verranno create automaticamente, in un secondo momento, all'interno di “CartellaAppositaPerIlMioSorgente” le cartella bin, lib ecc. e non dovrebbe essere necessario dare il comando finale di installazione con i privilegi di root in quanto non dovrebbero venire coinvolti cartelle e file di sistema.

In pratica dando il comando

./configure --help

potremmo avere un output di questo genere (dopo l'elenco dei comandi per abilitare o disabilitare alcune opzioni del programma):

........

By default, “make install” will install all the files in “/usr/local/bin”, “/usr/local/lib” etc. You can specify an installation prefix other than “/usr/local” using “--prefix”, for instance:

“--prefix=$HOMe”

For better control, use the options below.
Fine tuning of the installation directories:
--bindir=DIR user executables [EPREFIX/bin]

--libexecdir=DIR program executables [EPREFIX/libexec]

Oltre alle cose già viste, ci dice che per un miglior controllo del processo di installazione si può eventualmente scegliere di installare una (o alcune directory) specificatamente dove vogliamo noi.

Se vogliamo che ad esempio la directory “bin” (che contiene gli eseguibili) invece di essere creata all'interno di /usr/local (o di “CartellaAppositaPerIlMioSorgente” se diamo il comando “--prefix”), venga installata da un altra parte daremo il comando:

--bindir=percorso/dove vogliamo/mettere la/cartellabin

se invece della cartella “bin” vogliamo un alternativa per la cartella “libexec” daremo il comando

“--libexecdir=....” e così via.

Potrei, ad esempio, prevedere come directory di installazione “/usr” e poi indirizzare la cartella “man” che conterrà il manuale del programma in /usr/share/man. Senza questa seconda indicazione, le pagine del manuale con tutta probabilità sarebbero finite in /usr/man. Sulla base di quanto spiegato in precedenza, il comando da dare funzionerebbe così:

$ ./configure -–prefix=/usr --mandir=/usr/share/man

Immaginiamo ora di prevedere /usr come cartella di installazione e voler poi, come opzione prevista dal programma, caricare delle particolari librerie di sviluppo (svg), che quindi verranno attivate (enable), il comando sarà:

$ ./configure -–prefix=/usr --enable-librsvg

Se avessimo voluto disabilitare qualcosa avremmo usato: “--disable-nomedell'opzionedadisabilitare”.

Comunque da neofiti, se non necessario, sarà bene evitare queste varie opzioni che ingenerano confusione e inducono in errore, tuttavia è bene avere un idea di come funzionino soprattutto perchè ci potranno aiutare a capire i comandi utilizzati nello sviluppo dei pacchetti .deb.

Decisamente più interessante invece, l'alternativa che ci apprestiamo a descrivere, infatti invece di “./configure” si potrebbe digitare:

$ auto-apt run ./configure

Il comando "auto-apt run" entra in gioco quando “./configure” si accorge di qualche dipendenza irrisolta. Si occuperà di verificare se nei repository della nostra sources-list esista il pacchetto (o i pacchetti) mancante e ci chiederà il permesso di installarlo. Ovviamente si dovrà essere collegati ad internet, e sarà opportuno che siano abilitati quanti più repository possibili della nostra source list.

Per utilizzare questo programma sarà necessario installare il pacchetto “auto-apt” mediante Apt/Synaptic:

# apt-get install auto-apt

Va comunque detto che non è un programma molto affidabile in quanto spesso fallisce nella ricerca di alcuni pacchetti. Per quelli non trovati, dovremmo arrangiarci in prima persona a cercarli ed installarli.

E' quindi un'utility che può avere un senso, nel caso della compilazione di un sorgente con tantissime dipendenze, in cui a noi rimarrà solo il compito di installare il limitato numero di pacchetti non trovati da auto-apt.

Il motivo di queste “defaiilance” possono derivare dalla mancanza del pacchetto (o della versione corretta) nei repository che abbiamo in source-list, ma spesso vanno riferiti al modo con cui “./configure” trasmette l'indicazione di ciò che gli manca, poiché non sempre viene riportato con chiarezza il nome del pacchetto mancante. Questo può indurre in errore anche noi quando cerchiamo di risolvere queste dipendenze.

Ad esempio l'esecuzione del comando " auto-apt run ./configure " potrebbe terminare con un errore del tipo "SDL could not be found". Il comando “./configure” riferisce la mancanza di SDL, ma in realtà ciò che gli serve sono le "librerie di sviluppo SDL".

Voi cercherete in Synaptic questo fantomatico pacchetto "SDL"che “auto-apt” non trova ma che non potrete trovare nemmeno voi, perchè quello che serve in realtà, è un pacchetto di nome "libsdl1.2-dev".

Infatti, in genere le dipendenze che mancano a ./configure sono "librerie per sviluppatore", si tratta di pacchetti che, di solito, cominciano con la parola "lib" e finiscono con la parola "dev"

Per lo stesso motivo vi potrebbe venire richiesto un pacchetto che magari troverete già installato nella giusta versione, perchè il pacchetto che serviva davvero era: pacchettorichiesto-dev o libpacchettorichiesto-dev.

Normalmente chi prepara i pacchetti per le distribuzioni tende a dividere le librerie vere e proprie dagli “includes” cioè diciamo, per farsi un idea, gli “indici e i glossari” di queste librerie. Queste istruzioni vanno normalmente in pacchetti separati che hanno in genere il suffisso “dev” cioè “development” (in italiano “sviluppo”).

Per questo, quando si presenta un problema di dipendenze, partite dal presupposto che molto probabilmente (anche se non sempre) il pacchetto che dovete cercare in realtà comincia con "lib" e termina con "dev".

Make, come abbiamo già accennato, è il comando che si occupa di compilare il sorgente sulla base delle indicazioni contenute nel file “Makefile” creato da ./configure.

In pratica il “makefile” coordina la compilazione, quando viene avviata con il comando “make”, tenendo conto dello specifico “ambiente” in cui il programma viene compilato, cioè viene considerato il nostro computer con il suo processore (a 32 o 64 bit), il sistema operativo con il suo particolare filesystem, le librerie presenti ecc. Ciò è necessario perchè i vari sistemi Unix sono diversi tra loro in tanti piccoli dettagli, ma il programmatore mette a disposizione un sorgente che deve potersi installare sulla più ampia piattaforma possibile. Verra quindi compilato “ad hoc” grazie alle indicazioni del “makefile” ottenuto tramite i controlli (check) e i test di “./configure”.

Alcuni grossi programmi sono costituiti da tantissimi file sorgente, e compilarli tutti può richiedere molto tempo (ad es. la compilazione del sorgente di “Gimp” può richiedere anche una decina di minuti, a seconda della potenza della cpu).

Make controlla nel "makefile" le relazioni dei file che compongono il programma e sulla base di questi riferimenti crea, per ogni file sorgente, un file “oggetto” (avente estensione “.o”). Questi costituiscono una specie di tramite intermedio, per arrivare alla fine a generare il binario eseguibile.

Se anzichè installare state reinstallando un programma magari semplicemente per aggiornarlo, “make” ricontrollerà ogni file “.o” per capire se, rispetto all'ultima compilazione il file è cambiato, così da ricompilare solo i file differenti, facendovi risparmiare molto tempo, nel caso di un grosso programma.

Se durante un tentativo di installazione del sorgente qualcosa va storto, e volete ripetere la procedura, potrete scrivere:

$ make distclean

prima di eseguire nuovamente il comando "make", in questo modo verranno eliminati tutti file creati da make e quelli creati da configure come il “Makefile”, in pratica riporta le cose allo stato in cui erano quando avete spacchettato l’archivio, perciò potrete fare una ricompilazione pulita.

Se dopo aver installato il software vuoi liberare un po' di spazio sul disco fisso puoi eliminare i file intermedi e tutto quello che non serve, con:

$ make clean

In questo modo verranno lasciati intatti soltanto i files che permettono il funzionamento del programma.

In pratica vengono eliminati tutti i file creati con make ma non quelli di configure.

Si potrebbe utilizzare questo comando anche nel caso che per qualche motivo si voglia ripetere il processo di compilazione, senza voler rifare il ./configure in quanto si ritenga che quella fase sia stata soddisfatta e risolta correttamente (caso non frequente in quanto di solito i problemi, se ci sono, si presentano proprio a livello del configure).

Generalmente comunque make finisce il suo lavoro con il simpatico messaggio di “nothing to be done”, e questo significa che ha eseguito fino in fondo il suo compito.

Il fatto che la compilazione sia terminata con successo però, non vuol dire necessariamente che il software funzioni.

Alle volte è possibile effettuare dei test per verificare questo aspetto prima dell'eventuale installazione. Non è obbligatorio, ma conviene farlo:

$ make test

L'output potrebbe essere di questo tipo:

alter-1,1 ... Ok

alter-1,2 ... Ok

alter-1,3 ... Ok

altera-1,4 ... Ok

...

Thread specific data deallocated properly

0 errors out of 28093 test

Failures on these tests: 0

Il software è stato compilato bene e funziona correttamente.

Bene, ora avete l’eseguibile pronto, e tranne per alcuni casi, i programmi più semplici possono essere fatti girare anche senza essere installati nelle varie directory finali.

Dopo essersi portati sulla cartella contenente il binario eseguibile con cd, si lancerà:

$./nomeprogramma

Così si potrà utilizzare il programma senza installarlo. Si potranno tenere i programmi in una apposita cartella in modo da poterla recuperare in caso di formattazione, sarà sufficiente solo ricordare le dipendenze.

Non avremo una voce in MenuStart, per far partire il programma ma ci risparmieremo l'installazione finale con file estranei da inserire nel sistema. Comunque il più delle volte l'installazione definitiva è indispensabile per il funzionamento.

Nota. Anche se non avessimo una voce del programma inserita automaticamente in MenuStart si potrebbe però ottenere un link con icona sul desktop per avviare il programma cliccando col destro sul desktop e sceglendo “crea avviatore”, oppure si potrebbe inserire manualmente la voce con il link all'eseguibile del programma nel MenuStart utilizzando MX Menu Editor.

Problemi e difficoltà della compilazione

I comandi che abbiamo visto, soprattutto la fase di “configure” sono i più delicati dell'intero processo di installazione da sorgenti. Se qualcosa si inceppa di solito avviene in questa fase.

Gli errori più comuni sono spesso causati da una mancanza di una libreria condivisa o di un pacchetto. A volte basta concentrarsi sulle righe che riportano il testo "error" o "missing" per scoprire la soluzione del problema, non preoccupatevi invece troppo dei "warning". Nel caso in cui non si riesca ad andare avanti con la compilazione vi consigliamo di copiare l'intera riga riportante il codice dell'errore ed incollarlo su un qualsiasi motore di ricerca (Google) semmai unita alla parola «debian», è probabile che qualcuno abbia riscontrato lo stesso problema, trovando poi una soluzione. Inoltre utili indicazioni potrete ottenerle nel sito del progetto del programma in questione.

Se ci serve un file ad es “nomefile.h” e non sappiamo in quale pacchetto sia contenuto, ci si può appoggiare ad un'apposita funzione presente nel sito della distribuzione, vedi www.debian.org/distrib/packages. o https://packages.debian.org/search?keywords=search Si può digitare “nomefile.h” nel campo di ricerca e ci verrà indicato in quale pacchetto è contenuto. A quel punto potremo installare il pacchetto con Synaptic oppure con apt-get install nomepacchetto e riprendere la compilazione.

Vediamo ora alcuni casi particolari e possibili complicazioni.

Dando il comando “make” potrebbe comparire un messaggio d'errore tipo write access denied cioè “accesso in scrittura negato”, in pratica viene segnalata la mancanza del permesso per la scrittura nelle directory di sistema. In questo caso conviene digitare make in qualità di root

Controllate anche che i binari creati abbiano i giusti permessi di esecuzione per voi ed ogni altro utente appropriato.

Per impostare i permessi di esecuzione su tutti i files della directory del sorgente scompattato (dopo essersi portati all'interno con il comando cd) e rendere eseguibili gli script di configurazione, daremo questo comando:

# chmod +x *

Nota. L'asterisco mi permette di indirizzare il comando a tutti i files contenuti nella directory corrente (la cartella dove siamo piazzati con il terminale)

Le complicazioni più frequenti riguardano il problematico capitolo delle librerie.

Potrebbe succedere che siate sicuri di avere installato “tutte” le librerie richieste, compresi gli “includes” cioè libpacchettorichiesto-dev ma continuate a ricevere messaggi di librerie non trovate.

Questo può accadere per diversi motivi: potreste aver scaricato un tarball troppo vecchio o troppo nuovo per la vostra distribuzione, ad esempio potremmo avere scaricato la vecchia versione di “programmachevogliamoinstallare” che dipende dalla libreria “libreriachemiserve-2”, mentre noi abbiamo la “libreriachemiserve-3”.

Un altra possibilità è quella in cui la libreria necessaria è effettivamente presente nella versione giusta ma “./configure” non la trova in quanto non è nel posto che il sistema si aspetterebbe di trovarla. Alcuni programmi infatti, utilizzano delle librerie non standard, e spesso queste vengono collocate al di fuori delle directory standard predisposte per contenerle. Questo può capitare quando nel compilare un sorgente abbiamo bisogno di librerie non presenti nei repository e quindi non ottenibili attraverso apt/synaptic, perciò si sia deciso di fare ricorso ai sorgenti anche per le librerie mancanti. Si tratta di casi rari per l'abbondanza di librerie nei repository, in cui il neofita farebbe sicuramente bene a gettare la spugna, per evitare di trovarsi in un mare di guai nel portarsi a casa librerie non adeguatamente gestibili dai programmi di management del software; tuttavia immaginiamo che non ci si voglia fermare. In questo caso, il più delle volte, succede che si installino queste librerie in /usr/local ma che questa directory non sia nel percorso di ricerca delle librerie. Bisognerà specificare a configure l'esatto percorso (PATH, da non confondere con PATCH: pezza, aggiunta-modifica) per trovarla. Potrebbe essere in /usr/local come s'è detto oppure in qualsiasi altro posto “strano”. Per dirlo a configure bisognerà utilizzare i comandi che ci verranno segnalati allo scopo attraverso il comando “./configure --help”, in genere si tratta di qualcosa del genere:

$: ./configure –with-libreriachenonsitrova-dir=/strano/posto/lib/libreriachenonsitrova

Molto probabilmente la libreria in questione presenterà una cartella contenente la libreria vera e propria e un'altra con gli “includes”. Bisognerà allora aggiungere l'indicazione del percorso anche di questi, il comando risulterebbe così:

$: ./configure –with-libreriachenonsitrova-dir=/strano/posto/lib/libreriachenonsitrova –with-libreriachenonsitrova-includes=/strano/posto/include/libreriachenonsitrova

oppure bisognerebbe imparare ad usare ldconfig e il relativo /etc/ld.so.conf, cosa che esce dall'orizzonte di questa guida.

Altra possibilità abbastanza rara ma valida per avere un idea delle complicazioni insondabili (per il neofita) in cui ci si può imbattere: configure non trova la vostra libreria, voi avete indicato correttamente a configure la strada per trovarla, ma la compilazione si blocca. Se la libreria era stata compilata diverso tempo prima rispetto al sorgente che ne ha bisogno, e nel frattempo il nostro compilatore, ad esempio gcc- 2.95, è stato aggiornato, i cambiamenti dalle vecchie versioni a quelle nuove potrebbero essere state così consistenti da non permettere al nuovo gcc-3 di compilare un programma che si appoggia a delle librerie compilate col vecchio gcc-2.95.

Subito dopo il problema delle dipendenze, nelle varie articolazioni di cui abbiamo fatto qualche esempio, la difficoltà che capita più spesso è quella di scaricare sorgenti di applicazioni che non hanno nemmeno lo script configure . Chiaramente in questo caso il comando ./configure non produrrà alcun che perchè in realtà il vero comando è “./” dove il punto prima della slash dice al terminale di attivare il comando che segue, nella directory “corrente” , cioè dove siamo posizionati col terminale, mentre la slash serve ad attivare lo script avente il nome che segue quest'ultima. Chiaramente non essendo presente “configure” con il comando ./configure non si potranno attivare le funzioni che questo script codifica.

In tal caso possiamo essere di fronte a queste situazioni:

Si può trattare di sorgenti provenienti da repository CVS, SVN,o GIT. Si tratta di archivi utilizzati appositamente da programmatori per progetti in fase di creazione in cui viene messo in rete il sorgente del programma in sviluppo per meglio collaborare nel portarlo a termine. Qualche volta chi vuole le ultimissime novità di una determinata applicazione, scarica questi sorgenti, il principiante invece farà bene a tenersi alla larga, perchè le versioni CVS, SVN,GIT sono generalmente molto instabili e foriere di problemi.

Generalmente lo script configure in questi casi manca, ma al suo posto si trova quasi sempre qualcosa come cvscompile o autogen.sh, che servono appunto a creare, tra le altre cose, lo script configure.

Alcuni di questi piccoli script accettano anche i parametri di configure, per cui si potrebbe fare qualcosa come:

$: ./autogen.sh --help

Per creare lo script configure e avere allo stesso tempo la lista dei parametri passabili.

Se non dovessero esserci nemmeno “cvscompile” e “autogen.sh” potrebbe essere necessario compilare usando dei Makefile già pronti con comandi come:

$: make -f Makefile.cvs

o cose del genere precisate nei vari file README. INSTALL, BUGS ecc ecc, ma come già detto non sono cose che riguardano i lettori di questa guida, piuttosto può essere utile capire che ci stiamo trovando di fronte a un sorgente di questo tipo, per lasciarlo perdere.

Altre volte non esiste il file “configure”, ma al suo posto è presente un “configure.in”.

In teoria si potrebbe eseguire 'autoconf' e 'automake' quando esiste un file “*.am”, ma come nel caso precedente, se si vuole insistere, conviene provare la procedura descritta in “Creazione di pacchetti deb provenienti da sorgenti non ufficiali”.

Qualche volta non è presente il file “configure” perchè si tratta di applicazioni molto modeste in termini di dimensioni e richieste, per cui l’intero processo di compilazione si riduce al comando “make” che nel giro di alcuni secondi dovrebbe creare un eseguibile.

In questi casi probabilmente non è indispensabile installarli per farli funzionare, e qualche volta il “makefile”nemmeno prevede l'installazione.

Ad ogni modo non date per scontato di portare a termine felicemente la compilazione di un sorgente, è una pratica che richiede conoscenze non superficiali e un po' di esperienza, quindi le prime volte, mettete in conto di ottenere un risultato positivo in circa la metà dei casi, cercate informazioni in internet e se con “./configure” e “make” vi arenate provate la procedura per ottenere pacchetti .deb secondo lo standard debian, non è da escludere che cambiando la procedura riusciate a trovare la strada giusta.

Installazione

1-metodo classico makeinstall

Dopo la compilazione si può procedere con l'installazione del pacchetto, sarà necessario inserire la password poiché l’installazione di un programma richiede l’autenticazione con i diritti di amministratore di sistema.

$ su ([invio] password di root [invio])

# make install

Quella appena descritta è la procedura "classica" per installare un file a partire dai sorgenti.

In generale un programma, installato a partire da un pacchetto o da “binari non pacchettizzati deb”, si “sparpaglia” fra le diverse cartelle di sistema.

I file di configurazione di questo programma, ad esempio, finiranno nella cartella "/etc/", dove sono contenuti specificatamente questo tipo di file dei software installati.

I file che non saranno soggetti ad ulteriori modifiche (quindi il programma vero e proprio) finiscono in genere in una qualche sottocartella di "/usr/share/" o "/usr/local/", mentre i file che vengono modificati di solito vanno in "/var/".

Le librerie generalmente in "/usr/lib/" mentre il file per lanciare il programma, ovvero "l'eseguibile", lo dovremmo trovare in /usr/local/bin.

Per eseguire l'applicazione , se non è presente un link nel MenuStart, basta scrivere il nome dell'eseguibile nella console, oppure utilizzare MX Menu Editor per inserire il link all'eseguibile in MenuStart

2-metodo consigliato checkinstall

Come abbiamo visto, il programma si distribuisce in diverse cartelle seguendo una logica che è regolata da uno standard chiamato "Filesystem Hierarchy Standard (FHS)".

Tuttavia potrebbe capitare qualche problema nel disinstallare un programma se lo sviluppatore non aveva inserito un sistema per la disinstallazione, o se non si riesce per qualche motivo a rintracciare tutti i file installati.

Per questo si consiglia una procedura di installazione da sorgenti diversa dalla solita triade di comandi "./configure && make && make install".

Nota. I comandi visti nel paragrafo precedente potrebbero essere scritti nel terminale in un unica riga in questo modo, cioè utilizzando la doppia “&”. Il sistema darà esecuzione ad un comando, solo se quello precedente si è completato senza intoppi.

Per poter utilizzare questa metodica alternativa è necessario installare preventivamente il pacchetto checkinstall e fakeroot tramite Apt/Synaptic (è probabile che siano già presenti, ma meglio controllare)

# apt-get install checkinstall fakeroot

La procedura prevede che dopo aver compilato con “./configure && make”, invece di dare “make install” si darà questo comando in qualità di root:

$ su ([invio] password di root [invio])

# checkinstall

checkinstall crea un pacchetto .deb che potrà essere installato mediante “gdebi” o da terminale con “dpkg -i” In questo modo verrà anche aggiunto il pacchetto nel database dei pacchetti installati, rendendo così possibile la sua rimozione con Apt/Synaptic.

Anche con Dpkg si potrà eliminare, con questo comando:

$ su ([invio] password di root [invio])

# dpkg -r nomepacchetto

Ricordati che:

Nella creazione di determinati pacchetti checkinstall può non andare a buon fine. Per esempio Checkinstall ha qualche problema nella creazione di pacchetti che fanno uso di perl o script perl.

Checkinstall ha bisogno di un numero di versione per poter installare la vostra applicazione. Se dovesse mancare lo si può ingannare fornendogliene uno anche “finto”. Per fornire il numero di versione basta che la directory dei sorgenti dell’applicazione finiscano con un numero, ad esempio: Audacity-0.1.2.

Checkinstall non tiene traccia delle dipendenze necessarie per l’esecuzione dell’applicazione, per cui un deb creato con checkinstall andrà bene solo nel computer dove è stato creato.

Un programma installato con Checkinstall si comporta come un qualsiasi pacchetto DEB non ufficiale, come quelli che si trovano spesso in repository esterni, pertanto vi è la possibilità che risulti incompatibile con altri pacchetti già installati o con futuri aggiornamenti.

Sorgenti forniti dai repository

Prima di affrontare la procedura per la costruzione di questi pacchetti facciamo un breve preambolo per dire che i pacchetti debian sono molto utili non solo perché permettono di installare in modo rapido e semplice qualsiasi software senza doverselo compilare, ma anche perché grazie alla presenza di un database locale (per capirci, lo stesso che ci permette di vedere in Synaptic quanti pacchetti abbiamo installato, quanti sono aggiornabili ecc.), ciascun PC è sempre in grado di monitorare i pacchetti installati, le versioni disponibili, le librerie dipendenti e quindi di controllare lo stato totale del proprio PC.

Inoltre tutte le volte che installate software partendo dai sorgenti attraverso i classici ./configure&& make&&make install introdurrete nell hard disk una marea di dati che il più delle volte non sarete in grado di rintracciare e che ci si potrà scordare di eliminare (al momento opportuno) se non si sarà mantenuto un log oppure se il Makefile non supportava il make uninstall o simili.

Insomma, semplicemente il risultato è una gran quantità di files dispersi nel nostro HD non monitorati e difficili da cancellare.

Con l'installazione mediante checkinstall, la situazione è meno grave perchè, in caso di problemi, è possibile eliminare facilmente i files che lo compongono grazie ai gestori dei pacchetti che usiamo comunemente, questo perchè checkinstall da luogo a un pacchetto .deb anche se non in forma canonica, perciò grazie al database dei pacchetti presenti nei repository della nostra distribuzione possiamo in modo facile e trasparente sapere quale file appartiene al pacchetto X e quale a quello Y, e quindi con un semplice comando possiamo disinstallare il tutto in totale sicurezza qualora un programma non ci interessi più e si voglia recuperare lo spazio che occupava (tuttavia anche per il software installato con ceckinstall così come come con make install, permangono i limiti relativi alla possibile incompatibilità con qualche pacchetto soprattutto nel caso di aggiornamenti).

I pacchetti .deb compilati secondo la procedura Debian, rispetto a quelli ottenuti con ceckinstall, contengono molte più informazioni che permettono ai gestori dei pacchetti di compiere il loro lavoro in maniera più efficiente evitando possibili conflitti. Questo è il motivo per cui tendenzialmente conviene convertire i sorgenti in pacchetti .deb a nostro uso personale.

Diciamo che, in linea generale, per sorgenti di “driver” o altri software semplici checkinstall sarà la soluzione più pratica senza particolari controindicazioni, mentre per software complessi ricchi di dipendenze sarà più opportuno utilizzare la creazione di pacchetti deb in maniera canonica secondo la modalità Debian (anche se semplificata per un uso personale).

A volte (molto raramente) potrebbe essere necessario compilare direttamente i sorgenti presenti nei repository ufficiali della nostra distribuzione: magari per ottenere ottimizzazioni particolari oppure opzioni di compilazione che il pacchetto Debian non ha abilitato per default.

In questo caso sarà necessario abilitare il repo dei sorgenti presente in /etc/apt/sources.list.d/debian.list:

deb-src ftp://ftp.debian.org/debian/ jessie main contrib non-free

Basterà mettere il visto di fianco alla riga di questo repository in Synaptic –> impostazioni → archivi dei pacchetti, salvare e ricordarsi di cliccare il pulsante “Aggiorna” alla fine, oppure aprendo il file: /etc/apt/sources.list.d/debian.list togliendo il cancelletto (#) davanti alla riga che comincia per deb-src.

Per farlo devi essere amministratore. Puoi fare tutto da terminale così:

$ su ([invio] password di root [invio])

# leafpad /etc/apt/sources.list.d/debian.list

oppure graficamente utilizzando il classico FileManager (Thunar), poi raggiunta la cartella con il file che ci interessa cliccare col destro su uno spazio vuoto e nel menu a tendina scegliere “Open root Thunar here”.

Volendo si potranno inserire anche altre fonti di sorgenti, ad esempio:

deb-src http://www.debian-multimedia.org/ jessie main non-free

Come si vede, è stato sufficiente utilizzare deb-src al posto di deb, per ottenere che da uno stesso repository di binari si ricavino i rispettivi pacchetti di sorgenti (attenzione, nella gran parte dei casi è sufficiente questo, ma può capitare che alcuni repository abbiano i binari e i sorgenti dislocati in due indirizzi diversi, quindi è sempre consigliabile verificare l’esatta ubicazione di entrambi).

Altro motivo (più frequente) per ricorrere a questo tipo di sorgenti può essere la necessità di utilizzare una versione di un determinato pacchetto più recente rispetto a quella disponibile nel ramo “debian stable” utilizzato dalla nostra distribuzione ed, al tempo stesso, non si vuole installare da questa fonte direttamente il package compilato (con relative dipendenze, talvolta in numero ingente) preferendo generarne uno nuovo, che meglio si adatterà alle librerie presenti nel sistema.

Anche per la compilazione-costruzione dei pacchetti deb ci sono varie tecniche per procedere. Qui proporremo una modalità che fa uso del tool “dpkg-buildpackage”.

Prima di addentrarci a descriverla, diamo qualche accenno alla struttura dei pacchetti debian, in maniera da capire meglio i vari passaggi.

La policy debian dei sorgenti prevede che questi contengano al loro interno uno specifico albero di directory contenenti vari files, alcuni dei quali dovranno contenere precise informazioni sul sorgente, che non dovranno mancare in nessun pacchetto distribuibile.
Informazioni che vanno dal semplice nome del pacchetto, alla versione, alle dipendenze, agli script di pre-installazione e post-installazione.
Tale struttura ad albero è contenuta all'interno di una sottodirectory chiamata "debian"; al suo interno troviamo, tra i tanti, tre script per noi importanti:
Primo fra tutti il file “control”:

Package: acme
Version: 1.0
Section: web 
Priority: optional
Architecture: all
Essential: no
Depends: libwww-perl, acme-base (>= 1.2)
Pre-Depends: perl 
Recommends: mozilla | netscape  
Suggests: docbook 
Installed-Size: 1024
Maintainer: Joe Brockmeier [jzb@dissociatedpress.net]
Conflicts: wile-e-coyote
Replaces: sam-sheepdog
Provides: acme
Description: the description can contain free-form text
             describing the function of the program, what
             kind of features it has, and so on.
.
eccetera.

questo è un esempio di file control, contiene le informazioni visibili dagli utenti (tramite il gestore dei pacchetti o col comando “apt-get show nomepacchetto”) inerenti il pacchetto in questione, vediamo il nome del pacchetto, seguito dal numero di versione; la sezione alla quale appartiene il software che fornisce il pacchetto, l'architettura (32 o 64 bit) per la quale è stato compilato, le dipendenze, e tanti altri campi compresa una beve descrizione del pacchetto stesso.

Il secondo file che menzioniamo è il file “changelog”, che come il nome ricorda, contiene tutti cambiamenti di versione o tutte le revisioni che il pacchetto nel corso della sua esistenza ha subito, vediamo per esempio uno stralcio del file di changelog del pacchetto amule:

amule (2.2.1-1) unstable; urgency=low
  * The "I Don't Want to Get Over You" release.
  
eccetera.

quello che ci interessa maggiormente di questo file è la prima stringa che contiene il nome del pacchetto e la sua versione (il numero tra parentesi), che andrà a seguire il nome del pacchetto alla fine del processo.

Si noterà che vi è uno schema ben preciso per la nomenclatura dei pacchetti, in generale un nome di pacchetto deve essere cosi costituito:

nomepacchetto_versione_architettura.deb

tutti questi campi possono contenere caratteri speciali quali "+" "-" o la tilde "~" (si ottiene con Alt-Gr+ì);

Questa nomenclatura in genere non viene seguita da sorgenti provenienti da repository non ufficiali, di software in via di sviluppo.

I sorgenti all'interno di questi repository generalmente non sono "taggati" con una versione, in quanto sono file ad uso degli sviluppatori che non devono essere rilasciati, vengono invece identificati con un tag che viene chiamato numero di revisione, che indica il numero di modifiche che sono stati fatti su quei sorgenti; va da se che la revisione più alta corrisponde ai sorgenti più aggiornati. Al posto del numero di revisione talvolta (soprattutto nei repository svn) troviamo una vera e propria data, che indica appunto quando è stato effettuato l'ultimo aggiornamento.

prendiamo ad esempio un pacchetto di amule non proveniente dai repository ufficiali ma da uno di tipo CVS:

amule_2.2.0+CVS20080610_i386.deb

vediamo in primis il nome del pacchetto - amule - seguito dal numero di versione, che è 2.2.0, accompagnato dal numero di revisione preceduto dal carattere "+", poi il repository di tipo CVS, data e a seguire l'architettura sulla quale può essere installato questo pacchetto.

L'ultimo file che ci interessa è il file “rules”, che in sostanza è un makefile perche contiene le istruzioni per la compilazione del pacchetto.

La struttura che abbiamo sommariamente descritto è già predisposta e si sviluppa automaticamente nei sorgenti scaricati dai repository ufficiali debian ma non negli altri, quindi nel secondo caso va creata ricorrendo a dh-make, come vedremo nel prossimo paragrafo “Creazione di pacchetti deb provenienti da sorgenti non ufficiali”.

Dopo questo preambolo, cominciamo con la procedura installando i pacchetti che ci servono a questo scopo: build-essential, devscripts, dh-make, dpkg-dev fakeroot. Vediamo sommariamente a cosa servono:

• build-essential è un metapacchetto che dipende da libc6-dev, gcc, g++, make e dpkg-dev. Un pacchetto che potrebbe non risultare familiare è dpkg-dev. Contiene strumenti come dpkg-buildpackage e dpkg-source usati per creare, scompattare e compilare pacchetti sorgenti e binari.
• devscripts contiene molti script che rendono il lavoro del packager molto più facile. Alcuni dei più comunemente utilizzati sono debdiff, dch, debuild e debsign.
• dh-make è uno script che automatizza le operazioni comuni nella creazione dei pacchetti. dh-make può essere utilizzato per attuare una "debianizzazione" iniziale.
• fakeroot simula l'avvio di un programma con i privilegi di root. Questo è utile per creare pacchetti binari come normale utente.

In realtà non tutti sono indispensabili, alcuni (ad esempio dh-make) sono utili per la procedura che vedremo in uno dei prossimi paragrafi, comunque, già che ci siamo, installiamoli tutti via Synaptic, o con Apt così:

# apt-get install build-essential devscripts dh-make (dpkg-dev) fakeroot

Vediamo ora il caso elementare di una compilazione di un sorgente scaricato dal repository ufficiale debian stable, in cui si voglia intervenire apportando delle modifiche alla compilazione per attivare o disattivare funzioni particolari. Come esempio utilizziamo il sorgente di Audacity (un eccellente editor audio).

Innanzitutto, si controlla che tutte le dipendenze per compilare il programma siano presenti, anche semplicemente controllando in Synaptic, la linguetta “dipendenze” del pacchetto scelto. In caso negativo, si potrebbero installare sempre via synaptic, ma se fossero molte sarà più comodo farle installare in automatico da apt-get così (è bene, come con synaptic, che siano abilitati più repository possibili):

# apt-get build-dep audacity

Per usare l'utility “build-dep” è necessario che il pacchetto che vogliamo compilare abbia una versione nei repository (che è il caso affrontato da questo paragrafo).

Apt ci dirà che c'è bisogno di installare alcuni pacchetti. Noi risponderemo affermativamente e al termine avremo tutti i pacchetti necessari per la compilazione.

A questo punto possiamo scaricare il sorgente, naturalmente assicuriamoci di aver abilitato il repository dei sorgenti: “deb-src ftp://ftp.debian.org/debian/ lenny main contrib non-free” andando in synaptic e poi in impostazioni-> archivi dei pacchetti, poi diamo il comando:

# apt-get source audacity

I sorgenti verranno scaricati nella directory da cui si e' lanciato il comando.

Scaricato il sorgente, installate le dipendenze, si può procedere con la compilazione personalizzata.

Mostriamo due possibili metodi.

Metodo con modifica del files rules

$ ./configure

$ make

Entrate nella directory del sorgente, ad esempio “audacity-src-1.2.3-beta”. All'interno vedrete la famosa cartella di nome “debian” di cui si è parlato nell'introduzione del paragrafo. Entrandoci, tra i vari files, cercate il “rules”, il file che “dirige” le linee generali della compilazione, stabilendo regole, variabili e opzioni (una specie di “makefile”). Apritelo con un editor adatto allo scopo: leafpad e potrete modificarlo. Si potrà, per esempio, aggiungere la gestione del formato audio flac, disabilitata per default; la riga da modificare è questa:

DEB_CONFIGURE_EXTRA_FLAGS := --with-libsndfile=system

--with-vorbis=system --with-id3tag=system --with- libmad=system --without-libflac --with-nyquist

cambiando il --without-libflac in --with-libflac.

Salvate il file rules, quindi dalla directory principale di audacity date il comando per lanciare il processo vero e proprio di generazione del pacchetto debian:

$ debuild binary

Il comando si occuperà di compilare i sorgenti generando i binari, ed impacchettando il tutto in un pacchetto debian, con le vostre modifiche, che avrà come nome nomeprogramma_versione_architettura.deb

Altri esempi di modifiche apportabili nel files “rules” si possono vedere nel paragrafo: “Creazione di pacchetti deb provenienti da sorgenti non ufficiali”

Infine non rimarrà che installare il package appena creato con gli appositi comandi visti nei paragrafi riguardanti Gdebi, dpkg e l'installazione di pacchetti singoli, per esempio così

# dpkg -i audacity_1.2.3-1_i386.deb

Metodo con utilizzo del “configure”

Portandoci nella directory dei sorgenti, possiamo cominciare il processo di compilazione vero e proprio.

Configuriamo il pacchetto con le opzioni di configurazione, come abbiamo visto nel paragrafo in cui si parlava di “configure”.

Si darà “./configure --help” per capire la giusta sintassi richiesta dalla nostra modifica. Vedremo che, rispetto all'opzione che ci interessa attivare, sarà di questo tipo:

$ ./configure --option=option --option1=option1 --option2=option2

Perciò nel nostro caso il comando da dare sarà:

$ ./configure --with-libflac

(oppure $ ./configure --with-libsndfile=system --with-vorbis=system --with-id3tag=system --with- libmad=system --with-libflac --with-nyquist se volevamo attivare anche queste opzioni nel caso non fossero previste di default)

$ make

Quindi lanciamo il processo di generazione del pacchetto debian:

$ debuild binary

Infine installeremo il pacchetto

# dpkg -i audacity_1.2.3-1_i386.deb

Creazione di pacchetti deb provenienti da sorgenti non ufficiali

Il metodo che seguiremo magari non funzionerà al 100% ma con un buon numero di sorgenti dovrebbe andare a buon fine. Comunque, il metodo in sé non è particolarmente complicato:

Estraete i vostri sorgenti, inizialmente in forma di archivio compresso in una cartella a sé stante, in modo tale che i files “Makefile” e (se presente) “configure” si trovino direttamente all’interno; il nome di questa cartella è molto importante e deve rispecchiare lo standard debian, come abbiamo spiegato nel precedente paragrafo, secondo lo schema: nomepacchetto_versione_architettura.deb.

Attenzione, perché nomeprogramma deve essere tutto in minuscolo e può contenere solo caratteri, numeri, punti (.), più (+) o meno (-), mentre versione deve iniziare con un numero seppur i caratteri successivi possono contenere anche caratteri, punti…

Una directory chiamata "Nome_Pacchetto-a1.0" non è valida in quanto infrange la policy per i seguenti motivi:

• lettere maiuscole nel nome;
• carattere non consentito in quella posizione (il _ tra nome e pacchetto);
• versione con iniziale diversa da un numero.

Qualora, come in questo caso, non venissero rispettate le regole di denominazione, onde evitare warning & co., vi consiglio di rinominare la vostra directory, ad es in questo caso: Nome_Pacchetto-a1.0 → nome.pacchetto-1.0a

Una volta assicurati che la directory ha un nome accettabile ci entriamo:

$ cd nomeprogramma-1.2.3

Ora se all'interno è presente il file “configure” daremo i comandi visti in precedenza per generare il makefile (o per modificarlo se già presente) cioè daremo “./configure”eventualmente attivando qualche opzione visibile mediante “configure --help”, esattamente come abbiamo già descritto. In questo modo produrremo il “Makefile” (o lo modificheremo in maniera appropriata al nostro sistema se già presente).

Successivamente invece di dare semplicemente “make” come per i sorgenti ufficiali debian che sono già predisposti per diventare pacchetti debian, bisognerà dare un make in grado di intervenire per portare la struttura del sorgente che abbiamo scaricato ad assumere le caratteristiche volute da debian cioè ci deve essere la cartella Debian con dentro l'albero delle sotto-directory ecc. Questo “make particolare” è dh-make, come si è gia detto. Un aspetto molto importante di questo comando è che, se necessario, posso usarlo anche senza aver prima dato il comando “./configure” nei casi in cui lo script “configure” non sia presente.

Chiaramente dovrà almeno esserci un "makefile", altrimenti il sorgente non si compila. Le opzioni che potevano essere introdotte attraverso “./configure” si potranno attivare utilizzando dh-make.

Le varie opzioni, e relativa sintassi sono visibili dando il comando “dh-make --help”. Se volessimo compilare sorgenti da redistribuire la policy debian ci obbligherebbe a specificare molte informazioni ma poiché non è il nostro caso la quantità di informazioni da passare a dh-make è minore o in teoria nulla, ma qualche indicazione conviene darla avendo a che fare con sorgenti di origine eterogenea in cui non è scontato che vengano rispettati alcuni parametri standard debian utili per il funzionamento. Anche in questo caso come nei sorgenti ufficiali, queste opzioni-indicazioni-informazioni possono essere date attraverso comandi (./configure --opzione; dh-make --opzione) o andando a ritoccare direttamente i file (file control, file rules) dove questi comandi agiscono. Può essere pratico dare alcune indicazioni attraverso comando ed altre andando a ritoccare i files. Con la pratica ognuno trova il modo con cui si trova a proprio agio.

Vediamo cosa ci restituisce dh-make --help:

spippolo:~# dh_make --help
dh_make - Script to Debianize a regular source archive, version 0.46
Copyright (C) 1998-2008 Craig Small 
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
  Usage: dh_make [options]
  -c, --copyright     use  of license in copyright file
                            (gpl|lgpl|artistic|bsd)
      --dpatch              using dpatch to maintain patches
  -e, --email 
     use 
 as the maintainer e-mail address
  -n, --native              the program is Debian native, don't generate .orig
  -f, --file          specify file to use as the original source archive
  -r, --createorig          make a copy for the original source archive
  -s, --single              set package class to single
  -m, --multi               set package class to multiple binary
  -l, --library             set package class to library
  -k, --kmod                set package class to kernel module
  -b, --cdbs                set package class to cdbs
  -a, --addmissing          reprocess package and add missing files
  -t, --templates       apply customizing templates in 
  -d  --defaultless         skip the default debian and package class templates
  -o, --overlay        reprocess package using template in 
  -p, --packagename   force package name to be 
  -h, --help                display this help screen and exit
  -v, --version             show the version and exit
By Craig Small 
Based on deb-make by Christoph Lameter .
Custom template support by Bruce Sass .

Bene, dopo questa introduzione si può entrare nello specifico della procedura con questo comando:

$ dh_make -c gpl -e nostra_mail@email.it -r -s -p nomeprogramma-1.2.3

Il comando dh_make serve a creare una sottocartella ./debian/ "standard" dove saranno raccolti i files contenenti le impostazioni generali per creare un pacchetto .deb che verranno poi integrate nei passi successivi, un file .deb contiene infatti due archivi, uno (data.tar.gz) contenente i dati puri da estrarre nel vostro filesystem, mentre l’altro (control.tar.gz) contenente le informazioni sul pacchetto ed i dati dei files presenti e che permette di beneficiare della vera forza dei pacchetti (ossia l’aspetto “gestionale”).
I parametri indicati sono opzionali a dire il vero, cmq vediamo di spiegarli:
–c sta per copyright gpl serve invece a definire la licenza che copre il software da "pacchettizzare". Le possibilità sono gpl, lgpl, artistic, bsd (potete anche ometterla se il pacchetto è per “uso personale” )
-e nick@provider.com imposta l'email del creatore, quindi la vostra (può essere utile solo se ridistribuite il pacchetto);
-r crea un backup della cartella dei sorgenti prima di procedere alla creazione della cartella ./debian/ (invece con -n si dice a dh_make di non fare una copia di backup della cartella dei sorgenti. Se non avete fatto modifiche al codice e se avete sempre l’archivio iniziale non ha senso crearvi un backup (specie se avete parecchi MB di sorgenti);
-s serve ad indicare che state creando un pacchetto per un programma singolo (-m multiplo, -l libreria, -k per un modulo kernel) (se non lo sapete omettetelo, vi verranno chieste dopo altre informazioni);
-p forza il nome del pacchetto;

gli altri parametri li vedete facendo dh_make –-help

Andando ad aprire la nuova directory /debian che è appena stata creata, potremo trovare al suo interno il file "control" dove potremo scrivere con un editor di testo la descrizione del nostro pacchetto che sarà visibile attraverso Synaptic.

Per finire creiamo il nostro .deb vero e proprio:

$ debuild binary

...e come per magia apparirà un pacchetto .deb nella cartella superiore.

MA...UN ESEMPIO NO?

Prendiamo ad esempio il sorgente "DMitry-1.3a.tar.gz" ed estraiamo il pacchetto; otterremo la directory /DMitry-1.3a e (fatalità...) come vediamo il nome non funziona...quindi per prima cosa rinominiamo la directory "dmitry-1.3a".

A questo punto entriamo da terminale nella directory /dmitry-1.3a e creiamo il pre-pacchetto:

$ dh_make -c gpl -e spippolone@hotmail.it -r -s -p dmitry-1.3a

Otteniamo questa risposta:

Maintainer name : Pippolone

Email-Address : spippolone@hotmail.it

Date : Fri, 17 Oct 2008 17:38:02 +0200

Package Name : dmitry-1.3a

Version : 1.3a

License : gpl

Using dpatch : no

Type of Package : Single

Hit to confirm:

Clicchiamo per confermare...

Done. Please edit the files in the debian/ subdirectory now. dmitry-1.3a

uses a configure script, so you probably don't have to edit the Makefiles.

A questo punto andiamo a dare qualche spiegazione nel pacchetto che creeremo.

Entriamo nella directory /dmitry-1.3a e troveremo una nuova sotto directory /debian

Apriamo il file "control" e dentro troviamo questo:

Source: dmitry-1.3a

Section: unknown

Priority: extra

Maintainer: Spippolone @hotmail.it

>

Build-Depends: debhelper (>= 7), autotools-dev

Standards-Version: 3.7.3

Homepage:

Package: dmitry-1.3a

Architecture: any

Depends: ${shlibs:Depends}, ${misc:Depends}

Description:

Che andremo a sistemare a puntino...

Source: dmitry-1.3a => e ci va bene...

Section: network => la sezione di Synaptic

Priority: extra => ..per i comuni programmi.

Maintainer: Spippolone => generato da dh_help

Build-Depends: debhelper (>= 7), autotools-dev => automatico; è necessario avere le dipendenze installate!

Standards-Version: 3.7.3 => automatico

Homepage: http://mor-pah.net => La home-page del sorgente! (vedi: Note Finali)

Package: dmitry-1.3a => ci va bene

Architecture: i686 => l'architettura di compilazione, cioè la vostra (ricavabile dal comando "$ uname -m")

Depends: ${shlibs:Depends}, ${misc:Depends} => si arrangia apt-get

Description: DMitry (Deepmagic Information Gathering Tool) => il titolo della descrizione di Synaptic

UNIX/(GNU)Linux Command Line program coded purely in C

with the ability to gather as much information as possible

about a host.

=> La descrizione di Synaptic (ogni riga di descrizione deve iniziare con uno spazio o una tabulazione )

Bene, ora siamo pronti a creare il .deb, diamo (con il terminale dovremmo essere posizionati nella cartella ~/dmitry-1.3a):

$ debuild binary

...otteniamo questa risposta:

dpkg-checkbuilddeps: Unmet build dependencies: autotools-dev

debuild: fatal error at line 1283:

You do not appear to have all build dependencies properly met.

If you have the pbuilder package installed, you can run /usr/lib/pbuilder/pbuilder-satisfydepends as root to install the required packages, or you can do it manually using dpkg or apt using the error messages just above this message.

Per creare il pacchetto dobbiamo avere le dipendenze soddisfatte, ma (fatalità...) a noi manca "autotools-dev"...nessun problema:

# apt-get install autotools-dev

Dopo l'installazione della dipendenza mancante, possiamo passare alla creazione vera e propria del pacchetto:

$ debuild binary

Da qui si genera il tipico log di compilazione che qui ometto...fino all'ultima riga:

.....dpkg-deb: costruisco il pacchetto `dmitry-1.3a' in `../dmitry-1.3a_1.3a-1_i386.deb'.

se ora andiamo nella directory superiore a /dmitry-1.3a (nel mio caso la /home), troveremo un bellissimo .deb nuovo di zecca. Come vedete il nome non è proprio bellino; ma basta rinominarlo dmitry_1.3a_i386.deb e installarlo come un normale pacchetto.

Andando in Synaptic il nuovo pacchetto verrà visualizzato con tanto di descrizione e potremo installarlo su altre macchine.

NOTE FINALI:

- il comando dh_make potrebbe in teoria non prendere nessuna opzione, soprattutto se il pacchetto è a nostro uso personale. Da esperienza consiglio sempre di imporre il nome del pacchetto con l'opzione "-p"

Se scegliete di distribuire il pacchetto, *occhio alle licenze* perchè il pacchetto è vostro ma il sorgente no. Stessa cosa per i campi "description" e "Homepage" del file "control".

Se utilizzate il pacchetto su altre macchine, state attenti all'architettura perchè il .deb è compilato sulla vostra (nel mio caso una x86). Ovviamente la cosa è più importante se avete un 64 bit.

Altro Esempio

Vediamo un altro esempio… Tutto questo l’ho ottenuto creando il pacchetto di aMule 2.1.0.

• Estraete il file aMule-2.1.0.tar.bz2 che creerà una cartella ./aMule-2.1.0/ e che per quanto detto sopra dovrete rinominare in ./amule-2.1.0/
• Accedete a ./amule-2.1.0/ da shell con cd amule-2.1.0
• Dare il comando dh_make -s -e trevi55+public@gmail.com -n –copyright gpl
• ho modificato con un editor il mio file ./debian/control aggiungendovi una descrizione (ricordate che ogni riga di descrizione deve iniziare con uno spazio o una tabulazione)
• Quindi ho avviato la compilazione con debuild binary.
• Dopo «qualche» minuto ho avuto l’output atteso dpkg-deb: costruisco il pacchetto `amule’ in `../amule_2.1.0_i386.deb’. ed il mio pacchetto era nato!
• Ho installato il pacchetto con dpkg -i amule_2.1.0_i386.deb e tutto era funzionante!
  

Disinstallare pacchetti

Come ben sapete l'utilizzo dei repository è una comodità enorme per due motivi:

Primo, ci permette di trovare il software necessario in brevissimo tempo.

In secondo luogo, ci permette di installare e disinstallare ogni applicazione senza lasciare tracce.

Se il software non è presente nei repository e siamo costretti ad installare da sorgenti, il rischio è di lasciare “sporcizia” nel nostro sistema al momento della disinstallazione.

Se i pacchetti da voi installati erano dei .deb, o dei sorgenti installati usando il comando "checkinstall", dovrebbero essere facilmente rimovibili usando Synaptic.

Anche se il file README di un sorgente descrivesse come procedura di installazione l'uso di make install (dopo ./configure&make) cercate piuttosto di creare pacchetti deb secondo lo standard debian o almeno per mezzo del tool "checkinstall" che permette una rimozione molto più semplice.

Poiché in qualche caso queste procedure potrebbero non funzionare e si deve ripiegare su "make install" sarà bene abituarsi a installare i sorgenti sempre in un' apposita cartella ", così sarà più facile andarli a cercare per eliminarli.

Ci sono delle convenzioni per queste cartelle che consentono a noi di tenerle sotto controllo per mantenere la pulizia della nostra box, e al sistema di indirizzare le ricerche di librerie o altro, dove sa che potrà trovarle.

La cartella predefinita è quasi sempre /usr/local. Guardandoci dentro vedrete un piccolo “albero” simile a quello che si trova in /usr, quindi ci sarà /usr/local/bin corrispettivo a /usr/bin, /usr/local/lib corrispettivo a /usr/lib ecc ecc.

Il motivo di questi “doppioni” è che la directory /usr dovrebbe essere riservata ai files contenuti nei pacchetti più o meno ufficiali forniti dalla distribuzione linux che usiamo, mentre /usr/local dovrebbe appunto contenere quello che l'utente installa “in locale”. Questo facilita, tra l’altro, la “pulizia” e l’ordine della nostra box: infatti è molto più facile controllare se ci sono dei file inutili o indesiderati in /usr/local che nei meandri di /usr.

Se avevate installato compilando dei sorgenti con la forma:

./configure

make

make install

Cercare dove sono piazzati i sorgenti e provate a disinstallare usando "make uninstall" che cancellerà i files nelle varie cartelle dove si sono distribuiti dopo l'installazione.

Quindi portatevi nella directory dei sorgenti scompattati:

$ cd cartella_nomeprogramma

e date

# make uninstall

Naturalmente il file “Makefile”( o file-make) deve essere presente, quindi se avete cancellato i sorgenti e i sui file intermedi scompattate l'archivio e rieseguite lo script configure.

Il "make uninstall" comunque, potrebbe anche non funzionare, dipende se il programmatore ha in origine previsto il "make uninstall".

Se non dovesse attivarsi bisogna andare a cancellare manualmente i file, nelle directory dove si sono installati.

Sempre partendo dai sorgenti, fare il "makefile" e cercare i file.

Se quando avevamo installato il sorgente, avevamo attivato funzionalità particolari durante il “./configure” elencate con il comando:

$ ./configure --help

queste funzionalità andranno inserite anche in questa ricompilazione, perciò se avete installato un’applicazione e, dopo aver rimosso i sorgenti, volete disinstallarla usando make uninstall, dovrete

• rispacchettare il tarball in una directory qualsiasi;
• dare il configure con parametri identici a quelli che avete dato quando avete installato (almeno per quanto riguarda i vari --prefix con cui avete compilato);
• e solo dopo dare make uninstall.

Bibliografia:

http://linuxguide.altervista.org/Guida%20Xubuntu/gestore_pacchetti.html

http://www.sourceslist.eu/guide/aggiungere-le-chiavi-gpg/

http://guide.debianizzati.org/index.php/Pacchetti_binari_e_sorgenti

http://guide.debianizzati.org/index.php/Guida_ai_comandi_da_terminale_-_Gestione_di_repository_e_pacchetti

http://blog.3v1n0.net/creare-pacchetti-debian-a-partire-dai-sorgenti-guida-rapida/

https://pollycoke.wordpress.com/2004/11/17/compilare-sorgenti/

https://mxlinux.org/wiki

Guida realizzata da Spartak77 della community antiX e MX Linux

Versione 1 del 1/10/2016

Tutti i materiali sono liberamente riproducibili e modificabili, l'unico obbligo resta quello di citare le fonti.