Supponiamo di volere una versione del software più recente di quella disponibile per la mia versione attuale di un sistema operativo, cosa posso fare?
Casi da considerare:
- Ci sono fonti semiufficiali/ufficiali di pacchetti aggiuntivi
disponibili per quella versione del sistema operativo. Per esempio. backports.org per Debian
o PPA per Ubuntu. - Non sono disponibili versioni più recenti del pacchetto per quella
versione del sistema operativo, ma sono disponibili versioni più recenti per
versioni più recenti del sistema operativo. Questo è il caso standard per il
backporting. - Non sono disponibili versioni in pacchetto di versioni più recenti del software
. Le opzioni disponibili prevedono il pacchetto della versione
più recente.
Risposta accettata:
(Se hai domande/commenti su questa risposta, aggiungi un commento. Oppure, se hai abbastanza rappresentanti, puoi inviarmi un ping in chat.)
Installazione diretta di pacchetti binari da una versione più recente di Debian – non la risposta.
Supponiamo che tu stia eseguendo una versione di una distribuzione basata su Debian. Desideri una versione più recente di un pacchetto di quella disponibile. La prima cosa che ogni principiante prova a fare è installare il pacchetto binario direttamente sulla propria versione di Debian. Questo potrebbe funzionare o meno, a seconda della versione in esecuzione e di quanto è più recente il pacchetto. In generale, questa procedura non funzionerà bene.
Si consideri ad esempio il caso in cui si tenta di installare un pacchetto binario da testing/unstable direttamente su stable. Molto probabilmente non andrà bene, a meno che testing/unstable non sia molto vicino a stable in quel momento. Il motivo ha a che fare con la natura di una distribuzione binaria basata su Linux come Debian. Tali sistemi operativi dipendono fortemente dalle librerie condivise e queste dipendenze sono spesso strettamente dipendenti dalla versione; spesso molto più del necessario. Debian attualmente non ha un buon modo per rendere "strette" le dipendenze delle versioni, un modo abbreviato per dire che la dipendenza della versione è esattamente restrittiva quanto necessario.
Cosa significa questo per l'utente? Supponiamo ad esempio che tu stia tentando di installare, ad esempio slrn da Debian unstable a Debian stable. Come sarebbe?
# apt-get install slrn/unstable
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '1.0.1-10' (Debian:testing [amd64]) for 'slrn'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
slrn : Depends: libc6 (>= 2.15) but 2.13-38+deb7u1 is to be installed
E: Unable to correct problems, you have held broken packages.
Nonostante l'errore prodotto da apt , non ci sono pacchetti rotti qui. Allora, cosa è andato storto? Il problema è che la versione di libc6 che l'instabile slrn è stato compilato contro è diverso (e ha un numero di versione più alto) rispetto a quello disponibile su Debian stable. (libc6 è la libreria GNU C. La libreria C è fondamentale per qualsiasi sistema operativo simile a Unix e la libreria GNU C è la versione generalmente utilizzata dai sistemi operativi basati su Linux.)
Pertanto l'instabile slrn richiede una versione con numero più alto di libc6 di quanto non sia disponibile per la stalla. Nota che poiché un pacchetto è stato compilato su una versione superiore della libreria non richiede necessariamente una versione superiore di quella libreria, ma spesso è così.
La sintassi
apt-get install slrn/unstable
significa:usa l'instabile slrn ma per tutti gli altri pacchetti usa solo le versioni da stable. Per essere più precisi, utilizza i numeri di priorità. Vedi man apt_preferences per i dettagli.
Si può anche fare
apt-get install -t unstable slrn
È molto più probabile che funzioni, ma in genere non vuoi farlo. Perché?
Ciò significa:trattare temporaneamente tutti pacchetti in unstable su un piano di parità con i pacchetti in stable. Pertanto questo inserirà l'instabile slrn 's dipendenze da unstable se sono di un numero di versione più alto e generalmente lo saranno. Questo generalmente includerà la libreria GNU C per ragioni già spiegate. Ora, questo approccio generalmente "riuscirà", in quanto le dipendenze saranno soddisfatte per definizione (slrn di unstable ha dipendenze che sono soddisfatte in unstable), ma si finisce con un misto di pacchetti che improvvisamente vengono costretti a funzionare con versioni di librerie diverse da quelle per cui sono state create. Probabilmente non finirà bene.
La risposta è... BACKPORT!
Allora, qual è il modo corretto per farlo? Serve per ricostruire i sorgenti Debian di versioni più recenti sul tuo sistema, popolarmente noto come "backporting".
Considera i seguenti casi:
Ci sono fonti semiufficiali/ufficiali di pacchetti aggiuntivi disponibili per quella versione di Debian.
Il primo posto dove guardare è Debian Backports, che è il sito ufficiale per i backport Debian.
Per un esempio concreto:
Aggiungi la riga di backport appropriata per la tua versione e aggiorna per trovare i nuovi pacchetti, quindi installa qualcosa dai backport in modo esplicito (perché i backport sono disattivati per impostazione predefinita).
echo "deb http://ftp.debian.org/debian stretch-backports main" | sudo tee /etc/apt/sources.list.d/stretch-backports.list
sudo apt-get update
sudo apt-get install -t stretch-backports git
Questo otterrà l'ultima versione stabile di git che ha utili funzionalità più recenti rispetto a quella stabile inclusa con stretch (ad es. 'include' che ti consente di combinare più file di configurazione o cambiare il tuo nome utente per ~/work/projects/ vs ~/personal/ progetti/).
Un altro posto da guardare sono i vari PPA dei manutentori di Ubuntu. Puoi fare una ricerca per "nome pacchetto PPA".
Non sono disponibili versioni più recenti del pacchetto per quella versione del sistema operativo, ma sono disponibili versioni più recenti per versioni/rilasci più recenti del sistema operativo. Questo è il caso standard per il backporting.
Backporting significa ricostruire i sorgenti Debian da una versione successiva di Debian sulla versione in esecuzione. Questa procedura può essere facile o complicata e difficile a seconda del pacchetto. Ecco uno schema di come farlo.
Un breve tutorial di backporting per principianti
Per concretezza presumo che tu stia eseguendo l'attuale Debian stable, attualmente ansimante. Userò il pacchetto slrn come esempio.
Per prima cosa, nota che tutti i file di pacchettizzazione Debian risiedono in debian/ sottodirectory della directory di origine.
Il primo passo è verificare se è disponibile una versione più recente. Puoi farlo usando la apt-cache policy .
apt-cache policy slrn
slrn:
Installed: 1.0.0~pre18-1.3
Candidate: 1.0.0~pre18-1.3
Version table:
1.0.1-10 0
50 http://debian.lcs.mit.edu/debian/ testing/main amd64 Packages
50 http://debian.lcs.mit.edu/debian/ unstable/main amd64 Packages
*** 1.0.0~pre18-1.3 0
500 http://debian.lcs.mit.edu/debian/ wheezy/main amd64 Packages
100 /var/lib/dpkg/status
1.0.0~pre18-1.1 0
500 http://debian.lcs.mit.edu/debian/ squeeze/main amd64 Packages
Vorremmo eseguire il backport di 1.0.1-10 .
PASSO 1:
NB:assicurati che il deb-src le righe per la versione sorgente che desideri scaricare vengono visualizzate nel tuo /etc/apt/sources.list . Ad esempio, se desideri scaricare la versione unstable di slrn , hai bisogno di deb-src line per unstable, o non funzionerà. Nota che non hai bisogno del corrispondente deb righe per scaricare i sorgenti, tramite apt-cache policy utilizza tali informazioni, quindi se non hai il deb corrispondente righe, quindi apt-cache policy non ti mostrerà le versioni pertinenti. Se hai il deb righe, non dimenticare di bloccare le versioni più recenti utilizzando una voce in /etc/apt/preferences o simili. Una voce in /etc/apt/preferences in questo modo (per unstable) funzionerà, ad esempio.
Package: *
Pin: release a=unstable
Pin-Priority: 50
Se aggiungi righe in /etc/apt/sources.list , non dimenticare di eseguire apt-get update dopo.
Scarica i sorgenti per slrn . Un buon posto è /usr/local/src/slrn .
apt-get source slrn=1.0.1-10
PASSO 2:
Modifica leggermente il numero di versione, in modo da distinguere il tuo backport dalla versione upstream. Esegui dch --bpo , che aggiungerà automaticamente una voce al debian/changelog file con un numero di versione appropriato, ad esempio
slrn (1.0.1-10~bpo10+1) UNRELEASED; urgency=low
* Backport to buster.
-- User <[email protected]> Sun, 02 Feb 2014 23:54:13 +0530
PASSO 3:
Tentativo di costruire le fonti. Se i pacchetti richiesti per la compilazione non sono disponibili, il tentativo avrà esito negativo. Cambia directory nella directory di origine. Usa debuild dagli devtools pacchetto.
cd slrn-1.0.1/
debuild -uc -us
Se le dipendenze di build sono soddisfatte, i sorgenti costruiranno e produrranno alcuni debs al livello sopra la directory dei sorgenti; in questo caso /usr/local/src/slrn .
PASSO 4:
Supponiamo che le dipendenze di build non siano soddisfatte. Quindi devi provare a installare le dipendenze di build. Questo potrebbe funzionare o meno, poiché le dipendenze potrebbero non essere disponibili per la tua versione o, se disponibili, potrebbero non essere disponibili nella versione corretta.
NB:Sfortunatamente non è raro che i pacchetti Debian richiedano versioni delle dipendenze di build superiori al necessario. Non esiste un modo automatizzato in Debian per verificarlo, e spesso ai manutentori dei pacchetti non interessa finché funziona sulla versione/rilascio corrispondente. Pertanto, assumere un atteggiamento scettico nei confronti delle versioni delle dipendenze e utilizzare il buon senso. Ad esempio, pacchetti ampiamente utilizzati come Python e gli strumenti GNU non dipenderanno da versioni molto specifiche delle loro dipendenze, indipendentemente da ciò che il packager Debian elenca.
Correlati:Debian – Come possiamo prevedere quando uscirà la prossima versione di Debian?In ogni caso, puoi provare ad installarli facendo
apt-get build-dep slrn=1.0.1-10
Se l'operazione riesce, prova a creare nuovamente il pacchetto (PASSAGGIO 2). Se fallisce, è necessario ulteriore lavoro. Nota che debuild esamina le dipendenze di build in debian/control file e puoi modificarli se necessario. Quindi parliamone ora. Ecco le dipendenze di build per slrn.
Build-Depends: debhelper (>=9), libslang2-dev, libuu-dev,
exim4 | mail-transport-agent, libgnutls-openssl-dev, po-debconf, autoconf,
libcanlock2-dev, autotools-dev, dpkg-dev (>= 1.16.0), chrpath, dh-autoreconf, inn2-inews
Un'alternativa all'utilizzo di apt-get build-dep è installarli manualmente, facendo
apt-get install debhelper libslang2-dev ...
Se inizi a modificare questi valori nel file di controllo, dovresti passare a un'installazione manuale, come allora apt-get build-dep non farà più la cosa giusta.
Non sono disponibili versioni in pacchetto di versioni più recenti del software. Le opzioni disponibili prevedono il pacchetto della versione più recente.
In molti casi, è possibile riutilizzare la confezione di versioni precedenti del software insieme a fonti più recenti. Questo approccio può incorrere in problemi, in particolare le patch applicate alle versioni precedenti del software potrebbero non essere applicabili qui, quindi potrebbe essere necessario risincronizzarle con i sorgenti. Il formato sorgente 3.0 (quilt) che ora sta diventando standard usa quilt e le patch si trovano in debian/patches directory.
Tuttavia, una discussione dettagliata di questi problemi non rientra nell'ambito di questo post.