La recherche de packages plus récents est un problème courant sur n'importe quel système d'exploitation. Le cycle de publication de Debian a duré en moyenne 2 ans ces dernières années, donc vers la fin de ce cycle, c'est peut-être un problème plus urgent. Une façon d'atténuer cela est de passer aux tests vers la fin du cycle de publication stable, lorsque la prochaine version sera presque stable. Il ne ressort pas clairement de la question de savoir s'il s'agit de stable ou plus généralement de test et / ou instable. Quoi qu'il en soit, avoir la version la plus récente peut être un problème même si elle est instable, car la version la plus récente peut ne pas être encore packagée. Les développeurs / packagers Debian sont des volontaires, donc ils peuvent s'ennuyer ou s'occuper d'autres choses, avec pour conséquence que le paquet languit.
Pour plus de simplicité et de concrétisation, je suppose dans ce qui suit que le plan consiste à rétroporter un package vers stable, mais il s'applique plus généralement. Donc, voici ce que je fais si je veux une version plus récente d'un logiciel qui n'est pas présent dans stable, dans un ordre approximatif.
Recherchez le paquet dans Debian Backports . Parfois, vous pouvez trouver un package suffisamment récent pour répondre à vos besoins. Cependant, il arrive souvent que ces packages soient obsolètes par rapport à la version instable ou expérimentale ou en amont.
Essayez d'installer le package directement depuis testing, unstable ou experimental. Si stable n'a pas beaucoup divergé de la version à partir de laquelle vous essayez d'installer, cela peut fonctionner. Vous saurez que cette approche est mauvaise si le système commence à essayer d'installer ou de mettre à niveau des packages de base à partir de la version la plus récente. Supposons que vous essayez d'installer depuis instable, puis
apt-get install packagename/unstable
est la première chose à essayer. Avec les versions d'apt dans stable, cela échouera souvent, car cela nécessite d'autres packages de unstable, et cette incantation ne fait qu'augmenter la préférence de packagenamesuffisamment élevé pour qu'il soit installé dans unstable. Si vous ne comprenez pas ce que cela signifie, partez et lisez man
apt_preferences. Continuez à ajouter des dépendances à partir d'instable, en vous assurant qu'il n'essaie pas de mettre à niveau les packages de base. Par exemple, s'il commence à essayer de mettre à niveau libc6 ou X ou KDE ou Gnome, abandonnez immédiatement. C'est généralement bien s'il essaie de mettre à niveau d'autres packages à partir du même package source, car ceux-ci sont généralement étroitement couplés. Pour voir de quel paquet source dépend un paquet binaire, faites
apt-cache showsrc packagename
Comme beaucoup de choses dépendent de la bibliothèque GNU C (libc6), cela était un problème. Plus récemment, l'API semble s'être stabilisée, il est donc plus souvent possible de s'en tirer sans avoir à la mettre à niveau. Si un package satisfait ses dépendances d'exécution sur stable, mais ne fonctionne toujours pas correctement, signalez un bogue. Si le packager vous dit que ce n'est pas un bug, ils ont tort. :-)
Rétroportez vous-même le package des tests, instable ou expérimental.
Comme mentionné ci-dessus, les rétroportages sont une option, mais souvent ces packages sont obsolètes par rapport à la version instable ou expérimentale ou en amont.
Cela peut souvent nécessiter une chose de type boucle de génération de dépendance récursive. Vous devez d'abord obtenir les dépendances de construction avec
apt-get build-dep packagename
Si cela échoue car l'une des dépendances n'est pas assez récente, vous devrez d'abord rétroporter cette dépendance. Cela peut spriral hors de contrôle. J'abandonne généralement si je dois faire face à plus de 2 niveaux de récursivité. Notez cependant que les dépendances réelles ne sont pas nécessairement aussi étroites que celles citées, c'est-à-dire. une ancienne version peut fonctionner. Souvent, le packager n'essaie pas de trouver la version la plus ancienne d'une dépendance de build (ou, en fait, d'exécution) qui fonctionnera.
Vérifiez la disponibilité des packages à partir de l'amont correspondant. Idéalement, ceux-ci correspondraient à votre version de distribution, mais vous pourriez également être en mesure de les reconstruire si nécessaire.
Créez des packages pour la version du logiciel plus récente que les packages les plus récents dans testing / unstable / experimental. Cela peut être relativement difficile, mais toujours étonnamment réalisable. La première chose à noter est que si vous essayez de mettre en paquet une version plus récente d'un paquet qui est déjà dans Debian, vous commencez déjà avec un gros avantage, à savoir que vous avez le paquet existant avec lequel travailler. Fais juste
apt-get source packagename
et apt-gettéléchargera le paquet source correspondant, y compris le sous-répertoire debian où se trouve le paquet. Notez en outre que ces jours-ci, ce paquetage vit souvent à l'intérieur d'un référentiel de contrôle de verson (git semble populaire avec Debian) et stable apt (actuellement 0.8.10.3 ) vous indique utilement où cela se trouve lorsque vous l'invoquez
apt-get source. Vous devriez regarder cela, car les emballeurs peuvent avoir des versions plus récentes de l'emballage que ce qui correspond à n'importe quel paquet publié. Par exemple.
$ apt-get source mercurial
Reading package lists... Done
Building dependency tree
Reading state information... Done
NOTICE: 'mercurial' packaging is maintained in the 'Svn' version control system at:
svn://svn.debian.org/python-apps/packages/mercurial/trunk
Alternativement, vous pouvez simplement utiliser
apt-cache showsrc mercurial | grep Vcs
pour répertorier le référentiel.
Si le package n'est pas à jour, vous devrez peut-être apporter des modifications au
package, actualiser les correctifs appliqués, mais c'est généralement un bon
point de départ . Debian semble être en train de standardiser la gestion des paquets sur
quilt au format dpkg-source 3.0 (quilt) , ce qui aide à rafraîchir les correctifs.
Je conclurai par un exemple concret de la manière dont j'ai rétroporté le paquet Debian de
pgf . La dernière version packagée de pgf était 2.00 en 2008, et depuis lors, 2.10 avait été publiée. Voir la discussion dans Veuillez mettre à jour vers la dernière version stable de pgf (2.10) , et mon bogue de suivi avec un patch, pgf: patches contre l'empaquetage Debian 2.0 . En fait, le paquetage Debian de pgf était très simple, et je n'ai eu qu'à changer une ligne dans le paquetage 2.10 pour le faire fonctionner. J'ai fini par réprimer toutes les
plaintes lintiennes également, mais c'était strictement facultatif.