On Wed, 15 Mar 2006, Eric Mercier wrote: > nous envisageons la solution suivante : > > Un dépôt slis/ avec trois branches (stable / testing / unstable) > > Un dépôt sarge ( éventuellement ne contenant que les paquets nécessaires > à SLIS) > > Un dépôt updates (issu du security officiel qui aura été validé) > > > C'est là que je sollicite vos compétences : > > - y a t-il une meilleure solution ?
Je retourne la question, qu'est-ce qui ne te satisfait pas là-dedans ? Ton raisonnement m'a paru logique et la démarche aussi... > - concernant le dépot officiel sarge : est-ce qu'il peut arriver qu'il > subisse des modifications (mis à jour, etc) ? En d'autres termes, > devons-nous également surveiller les paquets disponibles dans sarge, > pour prévenir les éventuels effets de bords ? Oui sarge est mise à jour à chaque "révision" (3.1r2 étant la prochaine). http://wiki.debian.org/DebianReleases/PointReleases Ces révisions incluent la plupart des mises à jour de sécurité et d'autres mises à jour importante. On est très conservateur au niveau de ce qui est accepté mais cela pourrait évoluer à l'avenir maintenant que le responsable de ces mises à jour a changé (notamment en intégrant des paquets de "volatile"). Les mises à jour à venir sont disponibles dans les répertoires "stable-proposed-updates" des miroirs. > - est-il sérieux de valider "à la main" les mises à jour de security ? Globalement les MAJ de sécurité ne doivent rien casser, mais il est déjà arrivé que certains effets de bords soient gênants, cf la mise à jour de sudo qui fait perdre tout l'environnement ou la MAJ du noyau qui va nécessiter une mise à jour de l'installateur. A+ -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
