Supposons que je veuille 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. Aucune version plus récente du package n'est disponible pour
   cette version du système d'exploitation, mais des versions plus récentes sont disponibles pour
   les versions plus récentes du système d'exploitation. C'est le cas standard pour
   le rétroportage.
3. Aucune version packagée des versions plus récentes du
   logiciel n'est disponible. Les options disponibles consistent à empaqueter la version
   la plus récente.

Réponse acceptée :

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

Installer directement des packages binaires à partir d'une version plus récente de Debian – ce n'est pas la solution.

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 est d'installer le paquet binaire directement sur votre version de Debian. Cela peut fonctionner ou non, en fonction de la version que vous utilisez et de la date à laquelle le package est plus récent. En général, cette procédure ne fonctionnera pas bien.

Considérons par exemple le cas où l'on essaie d'installer un paquet binaire de 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-là. La raison est liée à la nature d'une distribution binaire basée sur Linux comme Debian. De tels 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 bien plus que nécessaire. Debian ne dispose pas actuellement d'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 slrn de Debian instable à 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 pas de paquets cassés ici. Alors, qu'est-ce qui a mal tourné ? Le problème est que la version de libc6 que le slrn instable a été compilé est différent (et a un numéro de version plus élevé) que celui disponible sur Debian stable. (libc6 est 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 généralement utilisée par les systèmes d'exploitation basés sur Linux.)

Par conséquent, le slrn instable nécessite une version numérotée supérieure de libc6 que ce qui est disponible pour stable. Notez que le fait qu'un paquet ait é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 :utiliser le slrn instable mais 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_preferences pour plus de détails.

On peut aussi faire

apt-get install -t unstable slrn

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

Cela signifie :traiter temporairement tous paquets dans unstable sur un pied d'égalité avec les paquets dans stable. Par conséquent, cela attirera le slrn instable les dépendances de 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 (le slrn d'unstable a 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érentes de celles pour lesquelles ils ont été construits. Cela ne finira probablement pas bien.

Connexe :limiter la sortie de recherche ET éviter le signal 13 ?

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 sur votre système, ce que l'on appelle communément le "backporting".
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 rétroportage appropriée pour votre version et mettez à jour pour trouver les nouveaux packages, puis installez explicitement quelque chose à partir des rétroportages (car les rétroportages 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 et utiles que la version 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 par les mainteneurs d'Ubuntu. Vous pouvez effectuer une recherche sur "nom du package 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 utilisez. Cette procédure peut être facile ou compliquée et difficile selon le forfait. 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 utilisez l'écurie Debian actuelle, actuellement sifflante. Je vais utiliser le package slrn à titre d'exemple.

Tout d'abord, notez que tous les fichiers d'empaquetage Debian résident dans le répertoire 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 le deb-src les lignes 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 du deb-src ligne pour unstable, ou cela ne fonctionnera pas. Notez que vous n'avez pas besoin du deb correspondant lignes pour télécharger les sources, via la apt-cache policy utilise cette information, donc si vous n'avez pas le deb correspondant lignes, puis apt-cache policy ne vous montrera pas la ou les versions pertinentes. Si vous avez le deb lignes, n'oubliez pas d'épingler les versions les plus récentes en utilisant une entrée dans /etc/apt/preferences ou similaire. Une entrée dans /etc/apt/preferences comme ceci (pour unstable) fonctionnera, par exemple.

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

Si vous ajoutez des lignes dans /etc/apt/sources.list , n'oubliez pas d'exécuter apt-get update après.

Télécharger 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 --bpo , qui ajoutera automatiquement une entrée au debian/changelog fichier avec un numéro de version approprié, par exemple

slrn (1.0.1-10~bpo10+1) UNRELEASED; urgency=low

  * Backport to buster.

 -- User <[email protected]>  Sun, 02 Feb 2014 23:54:13 +0530

ÉTAPE 3 :

Essayez de construire les sources. Si les packages requis pour la construction ne sont pas disponibles, la tentative échouera. Changez de répertoire dans le répertoire source. Utiliser debuild depuis les devtools paquet.

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 construction ne soient pas satisfaites. Ensuite, vous devez essayer d'installer les dépendances de construction. Cela peut fonctionner ou non, 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 packages Debian nécessitent des versions de dépendances de construction plus élevées que nécessaire. Il n'y a pas de moyen automatisé dans Debian pour vérifier cela, et souvent les responsables de paquets ne s'en soucient pas tant que cela 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 packages 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.

En relation :Debian – Comment prédire quand la prochaine version de Debian sortira ?

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). Si cela échoue, des travaux supplémentaires sont nécessaires. Notez que debuild examine les dépendances de construction dans debian/control fichier, 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 de apt-get build-dep est de 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 alors apt-get build-dep ne fera plus la bonne chose.

Aucune version packagée des versions plus récentes du logiciel n'est disponible. 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 appliqués 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 devient maintenant la norme utilise quilt, et les correctifs sont situés dans le répertoire debian/patches répertoire.

Cependant, une discussion détaillée de ces questions est hors de portée de cet article.