Le Wednesday 18 February 2009 23:10:56 Goldy, vous avez écrit : > Mathieu JANIN a écrit : > > Bonjour, > > sur une machine critique, aucun interet de passer en squeeze, ça va être > > pendant minimum un an la pire des trois solutions entre lenny, squeeze, > > et sid. Les paquets arrivant seront dans un état de compatibilité entre > > eux absolument non testés en plus du fait que la sécurité de chaque > > paquet n'est pas garantie, et les versions vont commencer à se succèder à > > rythme rapide en squeeze dans ce contexte instable. Ceci contrairement à > > la sid qui évolue sans à coup (un petit peu de mouvements avec la sortie > > de lenny, mais le dist-upgrade s'est fait sans incident pour moi) et > > malgré l'absence d'équipe sécurité et de menus défauts, reste plus stable > > que nombre de distribs annoncées comme des produits finalisés. > > Pour l'instant, donc, la squeeze va être destinée surtout aux bénévoles > > prets à se prendre les pires bugs en pleine face. > > Si tu veux des logiciels "cutting edge" prends une sid. Si tu ne veux > > pas prendre de risque, restes en Lenny. La squeeze, c'est pour rendre > > service aux autres en remontant les bugs. > > > > ++, MATT > > C'est surprenant que squeeze soit plus "dangereux" que sid, car selon ce > que l'on peut lire sur le site de debian, les paquets arrivant sur > squeeze doivent d'abord passer par sid pendant un certain temps. > > Il semble que la mise des paquets depuis sid dans la testing soit fait > automatiquement d'ailleurs. Justement, ce passage est bloqué s'il y a des bugs reportés dans sid. Du coup, on peut se retrouver avec des paquets manquant dans testing. Ca m'est arrivé à mes début, j'avais choisi testing, et il manquait des paquet autour de Xfree86... inutilisable. Je suis donc en sid depuis, et même si potentiellement il y a plus de bugs, il sont aussi corrigés plus vite. En effet, une correction de bug pour testing doit d'abord passer dans sid, attendre la fameuse période avant de basculer dans testing... Pour les problèmes de sécurité, c'était très embêtant, c'est pour celà que testing est maintenant prise en charge par l'équipe sécurité, qui peut passer outre l'attente dans sid. En résumé, pour moi : - serveur = stable - station de travail lambda = stable + backports - ma station de travail ou utilisateur expérimenté = unstable
Attachment:
signature.asc
Description: This is a digitally signed message part.