En tout cas, j'ai toujours vu/lu que testing était à éviter (exception faite comme dit plus haut par les mainteneurs de paquets).
Bof, j'ai utilisé testing longtemps, jamais eu de grosses merdes (sur un PC perso).
En gros, ça permets une meilleure stabilité qu'unstable (les paquets ont déjà passé des tests avant d'arriver dans testing) tout en étant plus récents que stable, surtout quand la stable tire sur sa fin de vie (stable backports fait pas tout)...
Un argument que j'avais vu sur la ML, par contre, c'était que oui, pour une machine que l'on veut sécurisée (genre un serveur), c'est la pire, parce qu'à l'époque stable avait le dépôt security, unstable était fréquemment mise à jour, mais en effet un bug dans testing pouvais ouvrir une faille qui mette du temps à être patchée. Depuis, il me semble qu'il existe un repo security pour testing?
Et si tu utilises testing, rien ne t'empêche, justement, d'intégrer des paquets unstable/experimental, vu que la version de la glibc sera plus probablement la même, moins de galères donc que quand tu mixes une stable ou une plus vieille avec d'autres versions.
Pour l'apt-pinning, petite précision: par défaut, les versions privilégiées serons celles configurées dans /etc/apt/apt.conf.d par une entrée de type: APT::Default-Release "buster";, et que l'apt-pinning (que je ne recommande pas a un débutant qui veut un truc qui juste marche) passe après cette clé...
[^] # Re: apt-pinning
Posté par freem . En réponse au message Installer un package de stable dans une debian testing. Évalué à 2.
Bof, j'ai utilisé testing longtemps, jamais eu de grosses merdes (sur un PC perso).
En gros, ça permets une meilleure stabilité qu'unstable (les paquets ont déjà passé des tests avant d'arriver dans testing) tout en étant plus récents que stable, surtout quand la stable tire sur sa fin de vie (stable backports fait pas tout)...
Un argument que j'avais vu sur la ML, par contre, c'était que oui, pour une machine que l'on veut sécurisée (genre un serveur), c'est la pire, parce qu'à l'époque stable avait le dépôt security, unstable était fréquemment mise à jour, mais en effet un bug dans testing pouvais ouvrir une faille qui mette du temps à être patchée. Depuis, il me semble qu'il existe un repo security pour testing?
Et si tu utilises testing, rien ne t'empêche, justement, d'intégrer des paquets unstable/experimental, vu que la version de la glibc sera plus probablement la même, moins de galères donc que quand tu mixes une stable ou une plus vieille avec d'autres versions.
Pour l'apt-pinning, petite précision: par défaut, les versions privilégiées serons celles configurées dans
/etc/apt/apt.conf.dpar une entrée de type:APT::Default-Release "buster";, et que l'apt-pinning (que je ne recommande pas a un débutant qui veut un truc qui juste marche) passe après cette clé...