Supponiamo che io voglia una versione più recente del software di quella disponibile per la mia attuale versione di un sistema operativo, cosa posso fare?

Casi da considerare:

1. Esistono fonti semi-ufficiali / ufficiali di pacchetti aggiuntivi disponibili per quella versione del sistema operativo. Ad esempio backports.org per Debian o PPA per Ubuntu.
2. Non ci sono versioni più recenti del pacchetto disponibili per quella versione del sistema operativo, ma sono disponibili versioni più recenti per le versioni più recenti del sistema operativo. Questo è il caso standard per il backporting.
3. Non sono disponibili versioni in pacchetto di versioni più recenti del software. Le opzioni disponibili sono il pacchetto della versione più recente.

^{Per compilazione di lasciare che un elenco di Q & A canonica questo è inteso come un posto dove mettere le risposte canoniche per il seguente. Probabilmente le risposte dovrebbero essere fatte wiki della comunità.}

(Se hai domande / commenti su questa risposta, aggiungi un commento. Oppure, se hai un rappresentante sufficiente, puoi chiamarmi in chat.)

Installa direttamente i 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. Volete una versione più recente di un pacchetto di quanto sia disponibile per voi. La prima cosa che ogni principiante tenta di farlo per installare il pacchetto binario direttamente sulla tua versione di Debian. Questo potrebbe funzionare o meno, a seconda della versione in uso e della versione più recente del pacchetto. In generale, questa procedura non funzionerà bene.

Consideriamo ad esempio il caso in cui si sta tentando di installare un pacchetto binario da testing / unstable direttamente su stable. Molto probabilmente questo non andrà bene, a meno che il test / instabile non sia molto vicino allo stabile 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 della versione - un modo abbreviato per dire che la dipendenza della versione è esattamente tanto restrittiva quanto necessaria.

Cosa significa questo per l'utente? Supponiamo ad esempio che stai cercando di installare dire slrnda 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. Quindi, cosa è andato storto? Il problema è che la versione di libc6ciò che unstable è slrnstata compilata è diversa (e ha un numero di versione superiore) rispetto a quella 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, unstable slrnrichiede una versione con numero superiore libc6rispetto a quella disponibile per stable. Si noti che poiché un pacchetto è stato compilato su una versione superiore della libreria non richiede necessariamente una versione superiore di quella libreria, ma spesso accade.

La sintassi

apt-get install slrn/unstable

significa: usa unstable slrnma per tutti gli altri pacchetti usa solo le versioni di stable. Per essere più precisi, utilizza i numeri di priorità. Vedi man apt_preferencesper 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 i pacchetti in unstable su un piano di parità con i pacchetti in stable. Pertanto, ciò porterà le slrndipendenze di unstable da unstable se hanno un numero di versione superiore e generalmente lo saranno. Ciò includerà generalmente la libreria GNU C per motivi già spiegati. Ora, questo approccio generalmente "avrà successo", in quanto le dipendenze saranno soddisfatte per definizione (le instabili slrnhanno dipendenze che sono soddisfatte in instabili), ma si finisce con una miscela di pacchetti che improvvisamente sono costretti a funzionare con versioni di librerie diverso da quello per cui sono stati costruiti. Questo probabilmente non finirà bene.

La risposta è ... BACKPORTS!

Quindi, qual è il modo corretto per farlo? Serve a ricostruire le fonti Debian di versioni più recenti sul proprio sistema, popolarmente conosciute come "backporting". Considera i seguenti casi:

Ci sono fonti semi-ufficiali / ufficiali di pacchetti aggiuntivi disponibili per quella versione di Debian.

Il primo posto dove cercare è 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 esplicitamente qualcosa dai backport (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 nuove funzionalità rispetto a quella stabile inclusa in stretch (ad esempio '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 / versioni più recenti del sistema operativo. Questo è il caso standard per il backporting.

Il backporting significa che devi ricostruire i sorgenti Debian da una versione successiva di Debian sulla versione in esecuzione. Questa procedura può essere semplice o complicata e difficile a seconda del pacchetto. Ecco una descrizione di come eseguire questa operazione.

Un breve tutorial di backporting per principianti

Per concretezza, suppongo che tu stia gestendo l'attuale scuderia Debian, attualmente sibilante. Userò il pacchetto slrncome esempio.

Innanzitutto, si noti che tutti i file di packaging Debian vivono nella debian/sottodirectory della directory di origine.

Il primo passo è verificare se è disponibile una versione più recente. Puoi farlo usando 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 effettuare il backport 1.0.1-10.

PASSO 1:

NB: assicurarsi che le deb-srclinee per la versione di origine che si desidera scaricare compaiano nel proprio /etc/apt/sources.list. Ad esempio, se si desidera scaricare la versione instabile di slrn, è necessaria la deb-srcriga per instabile o non funzionerà. Nota che non hai bisogno delle deblinee corrispondenti per scaricare le fonti, sebbene apt-cache policyusi quelle informazioni, quindi se non hai le deblinee corrispondenti , allora apt-cache policynon ti mostreranno le versioni rilevanti. Se hai le deblinee, non dimenticare di aggiungere le versioni più recenti usando una voce /etc/apt/preferenceso simile. Una voce /etc/apt/preferencescome questa (per unstable) funzionerà, per esempio.

Package: *
Pin: release a=unstable
Pin-Priority: 50

Se aggiungi le linee /etc/apt/sources.list, non dimenticare di correre in apt-get updateseguito.

Scarica le fonti per slrn. Un buon posto è /usr/local/src/slrn.

apt-get source slrn=1.0.1-10

PASSO 2:

Modificare leggermente il numero di versione, in modo da distinguere il backport dalla versione upstream. Esegui dch -i, che aggiungerà automaticamente una voce al debian/changelogfile. Quindi modificare la voce per assomigliare a questa, per esempio.

slrn (1.0.1-10.username) UNRELEASED; urgency=low

  * Backport to wheezy.

 -- User <user@domain>  Sun, 02 Feb 2014 23:54:13 +0530

PASSAGGIO 3:

Tentativo di creare le fonti. Se i pacchetti richiesti per la compilazione non sono disponibili, il tentativo fallirà. Cambia directory nella directory sorgente. Utilizzare debuilddal devtoolspacchetto.

cd slrn-1.0.1/
debuild -uc -us

Se le dipendenze di compilazione sono soddisfatte, i sorgenti costruiranno e produrranno alcuni debs al livello sopra la directory dei sorgenti; in questo caso /usr/local/src/slrn.

PASSAGGIO 4:

Supponiamo che le dipendenze di compilazione non siano soddisfatte. Quindi è necessario provare a installare le dipendenze di compilazione. Questo potrebbe non 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 di dipendenze di compilazione più alte del necessario. In Debian non esiste un modo automatico per verificarlo, e spesso ai manutentori dei pacchetti non importa se funziona sulla versione / versione corrispondente. Pertanto, assumere un atteggiamento scettico nei confronti delle versioni di dipendenza e utilizzare il buon senso. Ad esempio, i pacchetti ampiamente usati come Python e gli strumenti GNU non dipenderanno da versioni molto specifiche delle loro dipendenze, indipendentemente da ciò che elenca il packager Debian.

In ogni caso, puoi provare a installarli facendo

apt-get build-dep slrn=1.0.1-10

Se ciò ha esito positivo, prova a creare nuovamente il pacchetto (PASSAGGIO 2). Se fallisce, è necessario ulteriore lavoro. Si noti che debuildesamina le dipendenze di compilazione nel debian/controlfile e, se necessario, è possibile modificarle. Quindi parliamone adesso. 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 apt-get build-depè di installarli manualmente, facendo

apt-get install debhelper libslang2-dev ...

Se si inizia a modificare questi valori nel file di controllo, è necessario passare a un'installazione manuale, poiché in questo apt-get build-depmodo non si farà più la cosa giusta.

Non sono disponibili versioni in pacchetto di versioni più recenti del software. Le opzioni disponibili sono il pacchetto della versione più recente.

In molti casi, è possibile riutilizzare la confezione da 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 risincronizzarli con i sorgenti. Il formato sorgente 3.0 (quilt) che ora sta diventando standard utilizza quilt e le patch si trovano nella debian/patchesdirectory.

Tuttavia, una discussione dettagliata di questi problemi non rientra nell'ambito di questo post.

Un modo che funziona sempre, non solo in Debian, è compilare il software necessario da soli. (Lo sto facendo da anni su Debian, sia quando avevo bisogno di una versione più recente disponibile, sia quando il software non era affatto fornito).

Conservo i pacchetti compilati localmente in /use/localusing stow, il che mi consente di memorizzare tutti i file relativi a un pacchetto in un albero di sottodirectory e quindi di creare collegamenti simbolici a tale albero. Ciò semplifica la gestione dei pacchetti compilati: i file installati non si scontrano con i file forniti da Debian e posso rimuovere un pacchetto con un solo comando.

I passaggi per compilare e installare un pacchetto, ad esempio some_software, sono in genere una variante di quanto segue:

1. Scarica il .tarfile ecc /usr/local/src/. In.

2. Crea un file /usr/local/packages/some_softwareche descriva dove ho scaricato il software, che cosa fa, che versione è e che contiene note cosa ho dovuto fare per farlo compilare (vedi sotto).

3. Decomprimi il contenuto del .tarfile in /usr/local/tmp/some_software.

4. In alternativa, se la compilazione da un repository, controlla il repository in una sottodirectory appropriata (ad es. /usr/local/git/some_software) E compila lì,

5. cdin questa directory, guarda README, INSTALLecc.

6. Nella maggior parte dei casi, configurenel pacchetto è presente uno script autotools . Chiama con ./configure --prefix /usr/local/stow/some_software-versioncosì i file vengono installati in questa sottodirectory. Altrimenti, leggi Makefilee scopri come impostare il percorso per i file installati.

7. Compila con make.

8. Installa con make install.

9. cd /usr/local/stow, poi stow some_software-version

10. Verifica se funziona.

Spesso la compilazione non funziona al primo tentativo: il pacchetto potrebbe aver bisogno di librerie e dei corrispondenti file include, quindi è necessario installare i ...-devpacchetti corretti da Debian. O gccpuò lamentarsi di cose di gcccui non si lamenta una versione diversa di cui l'autore del pacchetto ha usato. Quindi a volte si deve leggere il codice e risolverli, ma ciò non accade troppo spesso.