Pour ma part, sur les serveurs j'ai besoin de paquets intensivement testés dans tous les sens et éventuellement (parque les « utilisateurs » veulent des chèvres à cinq pattes) quelques paquets plus récents. Du coup je met mes sources.list avec « stable » et « testing » et je positionne APT::Default-Release à « stable » dans /etc/apt/apt.conf.d/ (je n'aime pas du tout le mic mac de apt/preferences qui devient vite un gros bordel). De ce fait libc6 &co est forcément « testing », mais si on est pas trop pressé sur l'upgrade, ce sont des paquets vite corrigés. De temps en temps je fais quelques « downgrade » vers stable lorsqu'il le faut. Pour certains paquets pénibles (rares), je maintiens mon propre dépôt local avec des versions « testing » compilés avec pbuilder. = stable 990, testing 500 =
Pour le desktop, je veux bien des paquets récents et je veux bien suivre précisément testing (puisque mes serveurs possèdent quelque paquets). De plus, je pense que « testing » a besoin de « testeurs » comme son nom l'indique (il faut être motivé pour kdepim). Du coup je met mes sources.list avec « testing », « unstable » et « experimental » et je positionne APT::Default-Release à « testing » = testing 990, unstable 500, experimental 1, debian-multimedia (990,500) = Je suis pleinement satisfait de ces deux configurations couplées à apticron et apt-listbugs. Le seul gros soucis de « dist-upgrade » que j'ai en mémoire est le passage de sendmail il y a 4-5ans où nous avions fait des trucs crapuleux dans le .cf (depuis je fais un peu plus attention à la façon dont je modifie /etc/**) Cordialement, -- Eric DÉCORNOD Ingénieur d'Études SCICS - Faculté des Sciences Université Henri Poincaré