Dopo la nostra premessa passiamo alle guide vere e proprie.
Questa volta vedremo come adoperare i backports per installare versioni più recenti dei pacchetti per Debian. Come “scusa” per mostrare questo strumento supponiamo di voler installare una versione di Open Office più recente di quella presente nei depositi standard del software per Debian.
Ma lasciatemi spendere prima qualche parola su cosa siano questi “backports”. Di sicuro sarà qualche parola ovvia per molti lettori, ma non per chi si avvicina per la prima volta all’universo Debian (o più in genere a GNU/Linux) che potrebbe sentirsi spaesato, o peggio schiacciato, da tutti questi nuovi termini. Se conoscete già tutto o se siete interessati solo alla parte pratica di questa guida scorrete pure la pagina.
E allora cosa sono questi… cosi? Vediamone il significato punto per punto.
- Codice binario e codice sorgente. Facciamo un piccolo passo indietro. Il codice sorgente è un’insieme di informazioni che un programmatore scrive perché un computer possa eseguire ciò che serve: il “programma”. Queste informazioni sono scritte secondo determinate convenzioni (le convenzioni vengono dette linguaggi di programmazione) in una lingua molto simile a quella umana, tenendo conto dell’hardware su cui dovrà funzionare e di tutto il resto del software da cui dipenderà . Questo insieme di informazioni così scritte è detto appunto codice sorgente. Sfortunatamente, però, i processori non comprendono le lingue umane. Per questo motivo logica vuole che come passo successivo serva una traduzione da lingua umana a lingua pc-ese: questa traduzione è detta compilazione del codice sorgente. In questo modo si ottengono le stesse informazioni scritte dal programmatore però ora comprensibili dal processore del nostro pc: sono scritte utilizzando soltanto i numeri 0 e 1, e per questo motivo l’insieme di informazioni così ottenuto è detto codice bi-nario.
- Port. Passiamo alla seconda parte del termine backport. In genere, in informatica, per “port” si intende l’adattamento di un software ad un ambiente diverso da quello per cui è stato progettato, effettuato adattando il codice sorgente al nuovo ambiente e ricompilandolo. Questo può essere necessario a causa del fatto di voler utilizzare un programma nato per un certo sistema operativo (o anche per hardware specifico) su un altro tipo di sistema (o un altro tipo di hardware). Per esemplificare, è facile intuire che un programma nato e progettato per funzionare su Windows non potrà funzionare così com’è anche sulle nostre amate distribuzioni GNU/Linux: diverse librerie, diverse specifiche, diverso utilizzo di hardware, insomma così tante differenze dal sistema di Microsoft che il nostro programma sarà completamente inutilizzabile. L’unica soluzione sarà dunque adattare il software all’ambiente su cui dovrà operare: appunto sarà necessario effettuare un port.
- Back. Chiudiamo questa lunga premessa con la prima parte del termine. Ma per installare Open Office da dove viene fatto questo port? Il nostro obiettivo è utilizzare un pacchetto più recente di quello dei repository standard, per questo motivo utilizzeremo un port di una versione open office realizzata per un sistema operativo più recente. Ma quale? È facile intuire che più sono le differenze tra il sistema di origine del port e Debian, tante più saranno le modifiche di cui necessita il codice sorgente per poter funzionare e quindi tanto maggiore sarà la difficoltà che incontrerà chi effettua il port. Per questo motivo sono da scartare tutti i sistemi operativi “non linux” e tutte le distribuzioni diverse da Debian. E allora cosa resta? Le branche di sviluppo: Debian Testing, Unstable, ed Experimental. Ecco il siginficato di back: viene effettuato il port da questi repository più aggiornati indietro verso la nostra Debian Stable.
Concludendo, quindi, il backport è l’adattamento del codice sorgente di pacchetti di Debian Testing (o Unstable o Experimental) ricompilandolo poi in Debian Stable. Ovviamente tutto ciò non dovremo farlo noi in prima persona ma c’è un gruppo di sviluppatori che si preoccupa di fare tutto il lavoro e creare un apposito repository di pacchetti già “backportati” pronti per essere installati. Qui potete sfogliare tutti i pacchetti presenti in questo repository.
Parte pratica: mano agli attrezzi!
Ora che tutti sappiamo cosa siano i backports è ora di agire.
- Per prima cosa abilitiamo il repository dei backports. Apriamo un terminale e digitiamo:
$ su -c "nano /etc/apt/sources.list"
diamo invio e digitiamo la password del nostro account root.
- Scorriamo in basso e aggiungiamo la seguente riga:
deb http://www.backports.org/debian lenny-backports main contrib non-free deb http://backports.debian.org/debian-backports lenny-backports main contrib non-free(Ho corretto l’indirizzo come segnalato da Filippo nei commenti, NON dovete usare quell sbarrato). Salviamo con la combinazione di tasti Ctrl ed o, e successivamente Invio e chiudiamo con la combinazione Ctrl ed x.
- Perché il nostro gestore di pacchetti si renda conto dell’aggiunta di questo nuovo repository (e dei suoi pacchetti) dobbiamo aggiornare l’indice dei pacchetti. Ma prima dobbiamo inserire la chiave del nuovo deposito, dunque digitiamo in un terminale
su -c "wget -O - http://backports.org/debian/archive.key | apt-key add -"
Diamo invio e aspettiamo di leggere un bell’ “OK”. A questo punto siamo pronti per aggiornare l’indice dei pacchetti con un
su -c "aptitude update"
Bene! D’ora in poi aptitude e terrà a mente di poter contare anche su questi nuovi pacchetti.
- Apt (e quindi aptitude), a differenza di molti altri gestori di pacchetti, può assegnare priorità diverse a ciascun repository mediante l’assegnazione di un punteggio detto pin. A causa del fatto che Debian focalizza la propria attenzione sulla stabilità , e che nei backport sono presenti pacchetti molto più recenti, è assegnato di default una priorità molto bassa (cioè pin=1) al deposito dei backports, mentre una priorità molto più alta (cioè pin=500) al repository standard di Debian. Questo vuol dire che se ora installassimo Open Office con un semplice aptitude install openoffice.org apt installerebbe quello con il punteggio più alto, ossia quello dei repository standard di Debian e non quella dei backports. Insomma come se non avessimo fatto nulla. Per rendervene conto provate a dare il comando:
apt-cache policy
Come vedete ogni repository ha un proprio punteggio, ma solo le righe relative ai backport hanno il punteggio più basso: 1!!
Per ovviare a questo dobbiamo utilizzare l’opzione “-t lenny-backports“:su -c "aptitude install openoffice.org-core -t lenny-backports"
e diamo l’ok all’installazione di tutte le dipendenze. In questo modo aptitude capisce che deve momentaneamente utilizzare il repo lenny-backports come Target, cioè come repository con maggiore priorità . Sottolineo momentaneamente: dopo questo comando tornerà tutto come prima.
- Con il precedente comando abbiamo installato dai backports i file principali della suite, ma ora installiamo le singole componenti:
su -c "aptitude install openoffice.org-help-it openoffice.org-impress \ openoffice.org-java-common openoffice.org-l10n-it openoffice.org-math \ openoffice.org-pdfimport openoffice.org-writer openoffice.org-base \ openoffice.org-style-galaxy openoffice.org-style-oxygen openoffice.org-style-tango \ openoffice.org-style-industrial openoffice.org-style-hicontrast \ openoffice.org-style-crystal -t lenny-backports"
Molto probabilmente aptitude vi segnalerà la rottura di alcune dipendenze: niente paura! Aptitude è perfettamente in grado di trovare la soluzione migliore (per ogni soluzione assegna un punteggio finché questo è positivo dormite sonni tranquilli), quindi diamo l’ok e aspettiamo.
Ecco fatto! Ecco pronto il vostro nuovo Open Office scintillante!
Facoltativo: aggiornare automaticamente i pacchetti appena installati
Come ho già scritto l’opzione -t di aptitude ha un’azione “volatile”, cioè agisce solo per quel comando ma poi subito dopo il repository dei backports torna ad avere pin=1. Questo vuol dire che se ci fosse un’aggiornamento di openoffice in questi repository, non ce ne renderemmo conto. Potreste pensare, ok ma chissene…. ora ho le funzioni che mi servivano. Bè non è così: supponiamo che venga scoperta una falla nella sicurezza nella vostra suite di ufficio rischiereste di rendere visibile all’esterno i vostri documenti (magari con la contabilità della vostra azienda)?!?!? Direi di no. Ecco perché è utile che si aggiorni openoffice ogni qualvolta venga risolto un problema del genere. Vediamo come fare.
- Un’altra opportunità fondamentale che ci offre apt è quella di gestire il pinning persino pacchetto per pacchetto. Quindi diremo ad apt che SOLO per i pacchetti di open office dovrà tenere SEMPRE conto dei repository dei backports. Digitiamo
su -c "nano /etc/apt/preferences"
e inseriamo
Package: openoffice.org-base-core Pin: release a=lenny-backports Pin-Priority: 500 Package: openoffice.org-common Pin: release a=lenny-backports Pin-Priority: 500 Package: openoffice.org-core Pin: release a=lenny-backports Pin-Priority: 500 Package: openoffice.org-help-it Pin: release a=lenny-backports Pin-Priority: 500 Package: openoffice.org-impress Pin: release a=lenny-backports Pin-Priority: 500 Package: openoffice.org-java-common Pin: release a=lenny-backports Pin-Priority: 500 Package: openoffice.org-base Pin: release a=lenny-backports Pin-Priority: 500 Package: openoffice.org-l10n-it Pin: release a=lenny-backports Pin-Priority: 500 Package: openoffice.org-math Pin: release a=lenny-backports Pin-Priority: 500 Package: openoffice.org-style-hicontrast Pin: release a=lenny-backports Pin-Priority: 500 Package: openoffice.org-style-crystal Pin: release a=lenny-backports Pin-Priority: 500 Package: openoffice.org-style-galaxy Pin: release a=lenny-backports Pin-Priority: 500 Package: openoffice.org-style-industrial Pin: release a=lenny-backports Pin-Priority: 500 Package: openoffice.org-style-oxygen Pin: release a=lenny-backports Pin-Priority: 500 Package: openoffice.org-style-tango Pin: release a=lenny-backports Pin-Priority: 500 Package: openoffice.org-writer Pin: release a=lenny-backports Pin-Priority: 500
In questo modo abbiamo specificato che ciascuno dei pacchetti installati abbia pin 500 proprio rispetto al repository dei backports!
- Aggiorniamo ancora l’indice dei pacchetti con
su -c "aptitude update"
E il gioco è fatto, d’ora in poi quando aggiorneremo la nostra Debian terremo traccia anche degli aggiornamenti di Open Office nei Backports!
Ora abbiamo davvero finito, siamo pronti per utilizzare il nostro nuovissimo Open Office! Ovviamente ora che abbiamo imparato ad usare i backport possiamo usare lo stesso metodo anche per altri pacchetti! Buon divertimento!
Nota: Per ciascun comando che richiedesse i privilegi di amministratore ho utilizzato il formato su -c “<comando>” al posto di sudo <comando> perché ritengo sia il modo più sicuro di operare. Ciò non toglie che possiate usare il formato che più vi aggrada!
Ciao,
grazie per la pagina, ma perchè indichi
deb http://www.backports.org/debian lenny-backports main contrib non-free
e non
deb http://backports.debian.org/debian-backports lenny-backports main
come da pagina ufficiale del backport? cosa cambia? possiamo/dobbiamo metterli entrambi?
grazie,
Filippo
Ciao Filippo,
hai perfettamente ragione!!! L’indirizzo che ho scritto nel post è il VECCHIO indirizzo, mentre tu hai giustamente segnalato il nuovo! Il cambio è avvenuto solo qualche giorno fa e da grande sbadato quale sono ho dimenticato di modificarlo.
Provvederò subito!
Ti consiglio però ugualmente di aggiungere anche “contrib” e “non-free” alla fine.
Ciao.
Ciao Paolo,
grazie per la risposta. Colgo l’occasione per chiederti altro, perché può essere utile a tutti:
sempre nelle istruzioni ufficiali è riportato di creare il file delle preferenze e mettere:
# APT PINNING PREFERENCES
Package: *
Pin: release a=lenny-backports
Pin-Priority: 200
In questo modo tutti i pacchetti installati backport dovrebbero aggiornarsi automaticamente. Ma secondo te perchè la priorità è 200 e non 500 come visualizzato tramite “apt-cache policy” ?
Poi, se il pacchetto è stato via backports e se ne esce una nuova versione allora verrà aggiornato da BP, giusto? ma se non ho capito male questo avverà solo se ho manualmente aggiornato il pacchetto tramite l’opzione “-t lenny-backports”. E se volessi aggiornare l’intera mia lenny a BP e impostare e dare la priorità dell’aggioranamento a BP?
Grazie,
Filippo
Ciao Filippo grazie, per le domande.
Come dice qualcuno dobbiamo essere “wiki”!
Ti sono sempre più grato per le precisazioni di questo post che è sempre più a 4 mani!
Tornando a noi, ci sono due modi per avere gli aggiornamenti automatici, uno è quello di cui ho scritto nel post che ti permette di specificare pacchetto per pacchetto ciò che vuoi aggiornare automaticamente. L’altro modo è quello specificato nelle istruzioni ufficiali dei backport che ti permette di aggiornare in automatico tutto ciò che hai installato dai backport. Insomma ho scelto il primo perché lo ritengo più libero e flessibile e permette di scegliere di avere gli aggiornamenti SOLO per ciò che si vuole, tutto qui.
La differenza tra 500 e 200 sta nel fatto che 200 ti permette di aggiornare un pacchetto se hai installato già la sua precedente versione dai backports, ma se installi quel pacchetto per la prima volta sul tuo sistema, lo installerà dai repository ufficiali. Al contrario 500 invece soppianta completamente il repository ufficiali per quel pacchetto (spero di essere riuscito ad essere un po’ chiaro).
Sì, è giusto ciò che dici, inserendo quelle righe nel file preferences ti si aggiornerebbe in automatico tutto ciò che hai installato con -t lenny-backports, ma non il resto del sistema.
Per aggiornare invece *tutto* il sistema ti basta modificare quel 200 in 500, perché, come dicevo poco fa, 500 soppianta completamente i repository ufficiali per i pacchetti specificati (in questo caso tutti i pacchetti come indica l’asterisco alla voce Package).
Tutto lo schema dei pin è consultabile con man apt_preferences.
Spero di non averti confuso maggiormente, ma di essere stato chiaro.
ciao paolo, innanzitutto complimenti per il blog!
Avrei una domanda da farti sui backports e codice sorgente. Io uso Debian Lenny e devo installare un programma (per la cronaca Grass), nel repository c’è una versione precedente (6.2) del programma considerata stabile per il mio OS, nel repository backports ho la versione successiva (6.4) ma ‘rc’, la versione definitiva è disponibile solo in codice sorgente. La mia domanda è: posso compilare il sorgente dell’ultima versione sul mio OS, o mi conviene installare la versione backports dal repo? O addirittura mi consigli di restare con la 6.2? Io vorrei adottare la prima soluzione ma essendo un novizio di linux non so se posso compilare codice nuovo per OS “vecchi”(per modo di dire visto che lenny è l’ultima versione stabile…) e, nel caso, cosa rischio in termini di incompatibilità /stabilità . Grazie per i tuoi suggerimenti
claudio
Ciao Claudio, grazie mille per i complimenti! Sei il benvenuto!
Per quanto riguarda la compilazione potrebbe essere una buona palestra per capire come si compila un programma, perché no… Se non lo hai mai fatto prima, ti assicuro che passerai attraverso un buon cocktail di bestemmie, imprecazioni e brividi di paura fino all’urlo di gioia finale per esserci riuscito. Ma se non ti interessa più di tanto (o non ne hai il tempo e la possibilità di) imparare questo ora, allora credo che sarà un po’ una perdita di tempo. Infatti credo che si tratti di un programma un po’ pesante e quindi (a seconda della potenza della tua macchina) potrebbe richiedere anche qualche ora la compilazione. Inoltre utilizzare un programma non dai repository di Debian, vuol dire rinunciare ai vari piccoli aggiornamenti che avrai con il tempo, non saranno certo aggiornamenti di versione (con nuove feature per intenderci) ma in particolare saranno aggiornamenti di sicurezza per intenderci colmeranno falle che altrimenti permetterebbero a malintenzionati con sufficienti conoscenze di hacking di intrufolarsi nel tuo sistema e rubare le informazioni che vogliono, quindi aggiornamenti molto importanti specie se sarà usato in ambito lavorativo. Potresti rintracciare tu di volta in volta i problemi di sicurezza applicare la patch e ricompilare ancora, ma sarebbe davvero un dispendio notevole di tempo. Insomma direi che questa opzione è da scartare, almeno per ora.
Venendo ai backport non dovresti preoccuparti molto per il fatto che sia una RC, perché se è stata accettata in testing e quindi nei backport (ricordo che i backport sono pacchetti di debian testing “adattati” per debian stable) vuol dire che ha ricevuto un minimo di prove. Tra l’altro ho dato un’occhiata ai bug presenti per questa versione di grass qui e risultano attualmente scoperti solo due bug minori (quelli indicati con NORMAL mentre WISHLIST sono “suggerimenti” o “richieste” o “idee” per quel pacchetto, quindi in senso stretto non sono bug). Tu che adoperi GRASS e ne hai familiarità potresti essere più bravo di me a leggerne la descrizione e capire se effettivamente questi due bug sono fastidiosi o meno e se ne vale la pena o meno installare la versione dei backport o restare con la versione di debian stable per cui a quanto leggo da qui, invece, non sembra siano stati individuati bug fin’ora almeno dall’uscita di Lenny (14/02/09).
Insomma sembra che la versione di Lenny sia un po’ più immune da problemi. Tu solo però, leggendo la descrizione di quei due bug relativi alla versione dei backport, puoi capire se ne vale la pena o meno aggiornare ai backport facendo un bilancio tra i due bug e le nuove feature del programma. Ripeto questo bilancio puoi farlo solo tu che ne hai familiarità .