Re: etch et lenny
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é
Reply to: