Beaucoup de gens semblent craindre de mélanger stabilité et test, mais franchement, le test est assez stable et, avec les préférences et la vérification des solutions appropriées, vous pouvez éviter la "dérive de stabilité" qui met vos packages centraux sur le chemin instable.
"Le test est assez stable ??" , tu demandes. Oui. Pour qu'un paquet migre d'instable à testing, il doit avoir zéro bogue ouvert pendant 10 jours consécutifs. Il y a des chances pour que, surtout pour les paquets les plus populaires, quelqu'un soumette un rapport de bogue pour une version instable si quelque chose ne va pas.
Même si vous ne voulez pas mélanger les environnements, il est toujours agréable d’avoir cette option au cas où vous rencontriez quelque chose qui nécessite une version plus récente que celle qui est dans stable.
Voici ce que je recommande pour mettre cela en place:
Tout d’abord, créez les fichiers suivants dans /etc/apt/preferences.d:
stable.pref:
# 500 <= P < 990: causes a version to be installed unless there is a
# version available belonging to the target release or the installed
# version is more recent
Package: *
Pin: release a=stable
Pin-Priority: 900
testing.pref:
# 100 <= P < 500: causes a version to be installed unless there is a
# version available belonging to some other distribution or the installed
# version is more recent
Package: *
Pin: release a=testing
Pin-Priority: 400
unstable.pref:
# 0 < P < 100: causes a version to be installed only if there is no
# installed version of the package
Package: *
Pin: release a=unstable
Pin-Priority: 50
experimental.pref:
# 0 < P < 100: causes a version to be installed only if there is no
# installed version of the package
Package: *
Pin: release a=experimental
Pin-Priority: 1
(N'ayez pas peur des éléments instables / expérimentaux ici. Les priorités sont suffisamment faibles pour ne jamais installer ces éléments automatiquement. Même la branche testing se comportera, car elle ne fera qu'installer les packages que vous voulez installer. en test.)
Maintenant, créez un ensemble correspondant pour /etc/apt/sources.list.d:
stable.list: Copie de votre original /etc/apt/sources.list. Renommez l’ancien fichier en quelque chose comme sources.list.orig.
testing.list: Identique à stable.list, sauf avec testing.
unstable.list: Identique à stable.list, sauf avec unstable, et supprime les listes de sécurité.
experimental.list: Identique à unstable.list, sauf avec experimental.
Vous pouvez également ajouter un oldstabledans sources.lists.det preferences.d(utiliser une priorité de 1), bien que ce sobriquet aura tendance à expirer et disparaître avant le prochain cycle stable. Dans de tels cas, vous pouvez utiliser http://archive.debian.org/debian/et "coder en dur" la version de Debian (Etch, Lenny, etc.).
Pour installer la version de test d'un paquet, utilisez simplement aptitude install lib-foobar-package/testingou sautez simplement dans l'interface graphique d'aptitude et sélectionnez la version dans les détails du paquet (appuyez sur la touche entrée du paquet que vous regardez).
Si vous recevez des plaintes concernant des conflits de paquets, examinez d'abord les solutions. Dans la plupart des cas, le premier sera "ne pas installer cette version". Apprenez à utiliser les choix de résolveur accept / rejet par paquet. Par exemple, si vous installez foobar-package / testing et que la première solution est "n’installez pas foobar-package / testing", indiquez ce choix comme étant rejeté et les autres solutions ne basculeront plus jamais vers ce chemin. Dans de tels cas, vous devrez probablement installer quelques autres packages de test.
Si cela devient trop poilu (comme si on essayait de mettre à jour libc, le noyau ou un autre système central énorme), vous pouvez alors rejeter ces chemins de mise à jour ou simplement vous retirer de la mise à jour initiale. Rappelez-vous que la mise à jour des choses à testing / unstable ne sera possible que si vous le permettez.
EDIT: Correction de quelques pins de priorité et mise à jour de la liste.
