On Sun, Sep 30, 2007 at 05:46:08PM +0200, Marc Mongenet wrote: > deb http://http.us.debian.org/debian stable main contrib non-free > deb http://non-us.debian.org/debian-non-US stable/non-US main contrib non-free > deb http://security.debian.org stable/updates main contrib non-free > deb-src http://http.us.debian.org/debian stable main contrib non-free > deb-src http://non-us.debian.org/debian-non-US stable/non-US main > contrib non-free
Je recommande de toujours utiliser le nom physique de "stable", soit actuellement etch, de manière à pouvoir choisir, le jour où une nouvelle stable est activée, le moment idéal pour la mise à jour de la distribution entière; qui elle peut introduire des petites incompatibilités au plus grave, ou un downtime de quelques minutes des services systèmes en général. > - Pourquoi y a-t-il une ligne séparée pour security? http.us.debian.org > n'est-il jamais mis à jour? Le principe de Debian pour stable est quelque chose comme: par principe il n'y a AUCUNE mise à jour de *rien*. Ce qui garantit une stabilité exceptionnelle (on ne vous change pas le format des fichiers de configuration p.ex.) Il y a une exception évidente: les problèmes de sécurité. Ces mises à jour sont mises à disposition uniquement sur security. Il y a une autre exception: périodiquement, des "point-releases" sont faites: p.ex. 4.0r0, 4.0r1, 4.0r2, etc. Ces "point-releases" ont le droit de corriger AUTRE CHOSE que des problèmes de sécurité: p.ex. des bugs très graves. Elles intègrent également les mises à jour de sécurité (qui alors sont à double, à la fois sur security et à la fois dans la release normale). Par principe, stable garantit, en fait, que l'on peut conserver sa configuration telle quelle sans risque d'incompatibilité. Je ne me souviens que d'une exception, en 2002 ou 2003, quand OpenSSH n'a pas voulu donner un patch précis pour un bug mais a forcé toute les distributions à mettre à jour à une toute nouvelle version. En fait, Debian stable n'était même pas vulnérable, mais ils ont dû forcer un changement incompatible (heureusement avec un script de mise à jour automatisé, qui dans mon cas a parfaitement fonctionné). Ce genre de problème peut arriver avec Iceweasel: Le projet Firefox, plutôt que de donner des patches de 2 lignes pour des problèmes de sécurité, a tendance à faire des releases plus (trop?) complexes et forcer la mise à jour. En conséquence, Debian ne peut pas garantir que le backporting des corrections à la version stable restera possible à l'avenir. Cela figure dans les release notes. > - Pourquoi n'y a-t-il pas de ligne security pour debian-non-US? sauf erreur, debian-non-US est obsolète depuis sarge. Historiquement, les debian-non-US était pour des packages interdits d'exportation des Etats-Unis; le serveur était alors situé "ailleurs". Sauf erreur, security est également situé hors US. > - Pourquoi n'y a-t-il pas de ligne deb-src pour security? On peut la mettre. Les lignes deb-src ne servent qu'aux personnes faisant "apt-get source nom-du-package" à fin de recompilation (via dpkg-buildpackage). Je n'ai pas regardé plus en détail s'il n'y avait pas quelque chose de transcendant en plus. Si tu veux, tu peux faire un bug-report (sur debian-installer ou sur base-setup), en ajoutant la ligne -src concernée (voire plus bas). > PS: Aujourd'hui, en lisant Slashdot, j'ai aussi découvert l'existence de > deb http://volatile.debian.org/debian-volatile sarge/volatile main > contrib non-free Une exception de plus à la politique de stable: Debian a reconnu que certains logiciels *doivent* être mis à jour de manière très rapide, même s'il n'y a aucun problème de sécurité ou bug très grave concernant ces packages. La solution est volatile: on y trouve p.ex. les *données* et le *programme* clamav, p.ex. Pourquoi ? Certaines personnes n'aiment pas mettre clamav en mode "je cherche mes fichiers de signatures de virus tout seul", et préfèrent avoir ces données sous forme de packages versionnés (ce n'est pas mon cas).De plus, malheureusement clamav change fréquemment son exécutable (les fichiers de signatures deviennent incompatibles sans la mise à jour). volatile est là pour résoudre ces problèmes de manière supportée. Hors du support Debian, il y a encore backports.org. Et le système de "pinning" permet d'installer juste ce qu'il faut d'une autre distribution (p.ex. testing) tout en garantissant le fonctionnement du système. Et on peut aussi intégrer "proposed-updates" (mises à jour proposées de la point-release suivante), si on sait ce que l'on fait. Mon fichier sources.list: (sans les non-free, et sans mon miroir local, que je mets en premier pour des questions de performance. Je laisse les autres entrées en cas de problèmes de mise à jour de mon miroir). deb http://ftp.ch.debian.org/debian/ etch main contrib deb-src http://ftp.ch.debian.org/debian/ etch main contrib deb http://security.debian.org/ etch/updates main contrib deb-src http://security.debian.org/ etch/updates main contrib (j'y ajoute encore la ligne suivante pour mes propres packages: deb http://packages.cril.ch/cril/debian/packages/ etch cril) dans ce cas, pas de volatile non plus. PS: dans Debian, il n'est pas recommandé de mettre des sources d'installation de n'importe où. Une grande partie de la qualité de Debian provient du test et des standards de création de package. Donc sur une machine importante je ne mettrais rien en dehors de security et volatile. Il faut décider de cas en cas avec les backports, et installer minimalement (via le pinning). Il est évident qu'installer des packages "de n'importe où" via dpkg -i est quelque chose que l'on ne fait "jamais" sur un système Debian. _______________________________________________ gull mailing list gull@lists.alphanet.ch http://lists.alphanet.ch/mailman/listinfo/gull
