Supposons que je souhaite une version de logiciel plus récente que celle disponible pour ma version actuelle d'un système d'exploitation, que puis-je faire?

Cas à considérer:

1. Il existe des sources semi-officielles / officielles de packages supplémentaires disponibles pour cette version du système d'exploitation. Par exemple backports.org pour Debian ou PPA pour Ubuntu.
2. Il n'y a pas de versions plus récentes du package disponibles pour cette version du système d'exploitation, mais il existe des versions plus récentes disponibles pour les versions plus récentes du système d'exploitation. C'est le cas standard pour le rétroportage.
3. Il n'y a pas de versions packagées de versions plus récentes du logiciel disponibles. Les options disponibles consistent à empaqueter la version la plus récente.

^{Per Let's compilons une liste de questions et réponses canoniques, ce qui est destiné à mettre des réponses canoniques pour les éléments suivants. Les réponses devraient probablement être apportées au wiki communautaire.}

(Si vous avez des questions / commentaires sur cette réponse, veuillez ajouter un commentaire. Ou, si vous avez suffisamment de représentants, vous pouvez me cingler dans le chat.)

Installer directement des paquets binaires à partir d'une version plus récente de Debian - pas la réponse.

Supposons que vous exécutiez une version d'une distribution basée sur Debian. Vous souhaitez une version plus récente d'un package que celle dont vous disposez. La première chose que chaque débutant essaie de faire pour installer le paquet binaire directement sur votre version de Debian. Cela peut ou non fonctionner, selon la version que vous exécutez et la nouveauté du package. En général, cette procédure ne fonctionnera pas bien.

Considérons par exemple le cas où l'on essaie d'installer un package binaire depuis testing / unstable directement sur stable. Cela ne se passera probablement pas bien, à moins que testing / unstable ne devienne très proche de stable à ce moment. La raison tient à la nature d'une distribution binaire basée sur Linux comme Debian. Ces systèmes d'exploitation dépendent fortement des bibliothèques partagées, et ces dépendances dépendent souvent très étroitement de la version; souvent beaucoup plus que nécessaire. Debian n'a pas actuellement un bon moyen de rendre les dépendances de version «serrées» - une manière abrégée de dire que la dépendance de version est exactement aussi restrictive que nécessaire.

Qu'est-ce que cela signifie pour l'utilisateur? Supposons par exemple que vous essayez d'installer disons slrnde Debian unstable à Debian stable. À quoi cela ressemblerait-il?

# 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.

Malgré l'erreur produite par apt, il n'y a aucun paquet cassé ici. Alors, qu'est-ce qui a mal tourné? Le problème est que la version avec libc6laquelle l'instable a slrnété compilée est différente (et a un numéro de version plus élevé) que celle disponible sur Debian stable. ( libc6est la bibliothèque GNU C. La bibliothèque C est au cœur de tout système d'exploitation de type Unix, et la bibliothèque GNU C est la version que les systèmes d'exploitation Linux utilisent généralement.)

Par conséquent, l'instable slrnnécessite une version numérotée supérieure à libc6celle disponible pour stable. Notez que parce qu'un package a été compilé avec une version supérieure de la bibliothèque ne nécessite pas nécessairement une version supérieure de cette bibliothèque, mais c'est souvent le cas.

La syntaxe

apt-get install slrn/unstable

signifie: utilisez l'instable slrnmais pour tous les autres packages, utilisez uniquement les versions de stable. Pour être plus précis, il utilise des numéros de priorité. Voir man apt_preferencespour plus de détails.

On peut aussi faire

apt-get install -t unstable slrn

Cela est beaucoup plus susceptible de fonctionner, mais vous ne voulez généralement pas le faire. Pourquoi?

Cela signifie: traiter temporairement tous les packages dans unstable sur un pied d'égalité avec les packages dans stable. Par conséquent, cela tirera les slrndépendances de l'instable d'unstable si elles sont d'un numéro de version supérieur, et elles le seront généralement. Cela inclura généralement la bibliothèque GNU C pour les raisons déjà expliquées. Maintenant, cette approche "réussira" généralement, dans la mesure où les dépendances seront satisfaites par définition (unstable slrna des dépendances qui sont satisfaites dans unstable), mais vous vous retrouvez avec un mélange de packages qui sont soudainement forcés de s'exécuter avec des versions de bibliothèques différent de ce pour quoi ils ont été construits. Cela ne se terminera probablement pas bien.

La réponse est ... BACKPORTS!

Alors, quelle est la bonne façon de procéder? Il s'agit de reconstruire les sources Debian des versions les plus récentes de votre système, communément appelées «rétroportage». Considérez les cas suivants:

Il existe des sources semi-officielles / officielles de paquets supplémentaires disponibles pour cette version de Debian.

Le premier endroit à regarder est Debian Backports , qui est le site officiel des backports Debian.

Pour un exemple concret:

Ajoutez la ligne de backports appropriée pour votre version et mettez à jour pour trouver les nouveaux packages, puis installez quelque chose à partir des backports de manière explicite (car les backports sont désactivés par défaut).

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

Cela obtiendra la dernière version stable de git qui a des fonctionnalités plus récentes que celle stable incluse avec stretch (par exemple, 'include' qui vous permet de combiner plusieurs fichiers de configuration ou de changer votre nom d'utilisateur pour ~ / work / projects / vs ~ / personal / projets/).

Un autre endroit à regarder est les différents PPA des mainteneurs d'Ubuntu. Vous pouvez faire une recherche pour "packagename PPA".

Il n'y a pas de versions plus récentes du package disponibles pour cette version du système d'exploitation, mais il existe des versions plus récentes disponibles pour les versions / versions plus récentes du système d'exploitation. C'est le cas standard pour le rétroportage.

Le rétroportage signifie que vous reconstruisez les sources Debian à partir d'une version ultérieure de Debian sur la version que vous exécutez. Cette procédure peut être facile ou impliquée et difficile selon le package. Voici un aperçu de la façon de procéder.

Un bref tutoriel de rétroportage pour les débutants

Pour être concret, je suppose que vous exécutez l'actuelle Debian stable, actuellement sifflante. Je vais utiliser le package slrncomme exemple.

Tout d'abord, notez que tous les fichiers de packaging Debian vivent dans le debian/sous - répertoire du répertoire source.

La première étape consiste à vérifier si une version plus récente est disponible. Vous pouvez le faire en utilisant 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

Nous aimerions rétroporter 1.0.1-10.

ÉTAPE 1:

NB: Assurez-vous que les deb-srclignes de la version source que vous souhaitez télécharger apparaissent dans votre /etc/apt/sources.list. Par exemple, si vous souhaitez télécharger la version instable de slrn, vous avez besoin de la deb-srcligne pour unstable, ou cela ne fonctionnera pas. Notez que vous n'avez pas besoin des deblignes correspondantes pour télécharger les sources, mais apt-cache policyutilise ces informations, donc si vous n'avez pas les deblignes correspondantes , apt-cache policyne vous montrera pas la ou les versions pertinentes. Si vous avez les deblignes, n'oubliez pas d'épingler les versions les plus récentes en utilisant une entrée dans /etc/apt/preferencesou similaire. Une entrée /etc/apt/preferencescomme celle-ci (pour instable) fonctionnera, par exemple.

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

Si vous ajoutez des lignes /etc/apt/sources.list, n'oubliez pas d'exécuter apt-get updateensuite.

Téléchargez les sources pour slrn. Un bon endroit est /usr/local/src/slrn.

apt-get source slrn=1.0.1-10

ÉTAPE 2:

Modifiez légèrement le numéro de version, afin de distinguer votre backport de la version amont. Exécutez dch -i, qui ajoutera automatiquement une entrée au debian/changelogfichier. Modifiez ensuite l'entrée pour qu'elle ressemble à ceci, par exemple.

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

  * Backport to wheezy.

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

ÉTAPE 3:

Essayez de construire les sources. Si les packages requis pour la génération ne sont pas disponibles, la tentative échouera. Changez de répertoire dans le répertoire source. Utiliser à debuildpartir de l' devtoolsemballage.

cd slrn-1.0.1/
debuild -uc -us

Si les dépendances de construction sont satisfaites, alors les sources vont construire et produire des debs au niveau au dessus du répertoire source; dans ce cas /usr/local/src/slrn.

ÉTAPE 4:

Supposons que les dépendances de génération ne soient pas satisfaites. Ensuite, vous devez essayer d'installer les dépendances de génération. Cela peut ou peut ne pas fonctionner, car les dépendances peuvent ne pas être disponibles pour votre version, ou si elles sont disponibles, peuvent ne pas être disponibles dans la bonne version.

NB: Il n'est malheureusement pas rare que les paquets Debian nécessitent des versions de dépendances de construction plus élevées que nécessaire. Il n'y a aucun moyen automatisé dans Debian de vérifier cela, et souvent les responsables de paquets s'en moquent tant qu'il fonctionne sur la version / version correspondante. Par conséquent, adoptez une attitude sceptique vis-à-vis des versions de dépendance et faites preuve de bon sens. Par exemple, des paquets largement utilisés comme Python et les outils GNU ne dépendront pas de versions très spécifiques de leurs dépendances, quelle que soit la liste du packager Debian.

Dans tous les cas, vous pouvez essayer de les installer en faisant

apt-get build-dep slrn=1.0.1-10

Si cela réussit, essayez à nouveau de construire le package (ÉTAPE 2). S'il échoue, des travaux supplémentaires sont nécessaires. Notez que debuildexamine les dépendances de construction dans le debian/controlfichier et vous pouvez les modifier si nécessaire. Alors parlons-en maintenant. Voici les dépendances de construction pour 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

Une alternative à l'utilisation apt-get build-depconsiste à les installer manuellement, en faisant

apt-get install debhelper libslang2-dev ...

Si vous commencez à modifier ces valeurs dans le fichier de contrôle, vous devez passer à une installation manuelle, car apt-get build-depcela ne fera plus la bonne chose.

Il n'y a pas de versions packagées de versions plus récentes du logiciel disponibles. Les options disponibles consistent à empaqueter la version la plus récente.

Dans de nombreux cas, on peut réutiliser l'emballage des versions antérieures du logiciel en conjonction avec des sources plus récentes. Cette approche peut rencontrer des problèmes, notamment les correctifs qui s'appliquaient aux versions antérieures du logiciel peuvent ne pas s'appliquer ici, il peut donc être nécessaire de les resynchroniser avec les sources. Le format source 3.0 (quilt) qui est en train de devenir standard utilise quilt et les patchs sont situés dans le debian/patchesrépertoire.

Cependant, une discussion détaillée de ces questions est hors de portée pour ce poste.

Une façon qui fonctionne toujours, pas seulement dans Debian, est de compiler vous-même le logiciel nécessaire. (Je fais cela depuis des années maintenant sur Debian, à la fois lorsque j'avais besoin d'une version plus récente qui était disponible et lorsque le logiciel n'était pas du tout fourni).

Je stocke des packages compilés localement dans /use/localusing stow, ce qui me permet de stocker tous les fichiers liés à un package dans une arborescence de sous-répertoires, puis de créer des liens symboliques vers cette arborescence. Cela facilite la gestion des paquets compilés: les fichiers installés n'entrent pas en collision avec les fichiers fournis par Debian, et je peux supprimer un paquet avec une seule commande.

Les étapes pour compiler et installer un package, par exemple some_software, sont généralement une variante de ce qui suit:

1. Téléchargez le .tarfichier etc. dans /usr/local/src/.

2. Créez un fichier /usr/local/packages/some_softwarequi décrit où j'ai téléchargé le logiciel, ce qu'il fait, de quelle version il s'agit et qui contient des notes sur ce que j'ai dû faire pour le compiler (voir ci-dessous).

3. Décompressez le contenu du .tarfichier dans /usr/local/tmp/some_software.

4. Sinon, si vous compilez à partir d'un référentiel, consultez le référentiel dans un sous-répertoire approprié (par exemple /usr/local/git/some_software) et compilez-le,

5. cddans ce répertoire, regardez README, INSTALLetc.

6. Dans la plupart des cas, configurele package contient un script autotools . Appelez avec ./configure --prefix /usr/local/stow/some_software-versionafin que les fichiers soient installés dans ce sous-répertoire. Sinon, lisez Makefileet découvrez comment définir le chemin d'accès aux fichiers installés.

7. Compilez avec make.

8. Installez avec make install.

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

10. Testez si cela fonctionne.

Souvent, la compilation ne fonctionne pas du premier coup: le paquet peut avoir besoin de bibliothèques et des fichiers include correspondants, il faut donc installer les bons ...-devpaquets depuis Debian. Ou gccpeut se plaindre de choses dont une version différente gccdont l'auteur du package utilisé ne se plaint pas. Il faut donc parfois lire du code et les corriger, mais cela n'arrive pas trop souvent.