C’est le rôle de « testing ». C’est plus un « bassin de décantation » de Sid, dans lequel les dépendances sont toujours cohérentes qu’une véritable distribution à part entière. Pour les problèmes de sécurité, les délais sont accélérés, mais le processus reste le même, rien n’entre dans « testing » sans maturation/validation préalable. Il faut bien comprendre qu’au départ « testing » n’était qu’une étape intermédiaire entre Sid et la nouvelle « stable » pour assurer sa cohérence, dans l’espoir de gagner du temps pour la sortie (avec un succès très relatif).
Le délai entre Sid et « testing » restera toujours, et pour du « responsible disclosure », Sid est corrigé au moment de l’annonce officielle, et donc « testing » traîne un peu.
En pratique, ça signifie qu’il ne faut pas utiliser « testing » seule. Sur un serveur, on laisse « stable » [0] de toute façon. Sur son ordi perso, on pioche dans Sid lors des annonces de sécurité (ou on ajoute un dépôt tiers pour la sécurité, solution qui devrait être adoptée pour Debian CUT si le projet aboutit).
[0] qui n’a été affecté ni par le bug Debian dans le générateur de nombres aléatoires, ni par celui-ci et dispose de dépôts de sécurité propres. Certaines failles surviennent évidemment en « stable » aussi, mais le niveau général de sécurité de cette distribution est incomparablement meilleur que les autres branches, voire que beaucoup de distrib’s.
[^] # Re: FreeBSD
Posté par jyes . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 2.
C’est le rôle de « testing ». C’est plus un « bassin de décantation » de Sid, dans lequel les dépendances sont toujours cohérentes qu’une véritable distribution à part entière. Pour les problèmes de sécurité, les délais sont accélérés, mais le processus reste le même, rien n’entre dans « testing » sans maturation/validation préalable. Il faut bien comprendre qu’au départ « testing » n’était qu’une étape intermédiaire entre Sid et la nouvelle « stable » pour assurer sa cohérence, dans l’espoir de gagner du temps pour la sortie (avec un succès très relatif).
Le délai entre Sid et « testing » restera toujours, et pour du « responsible disclosure », Sid est corrigé au moment de l’annonce officielle, et donc « testing » traîne un peu.
En pratique, ça signifie qu’il ne faut pas utiliser « testing » seule. Sur un serveur, on laisse « stable » [0] de toute façon. Sur son ordi perso, on pioche dans Sid lors des annonces de sécurité (ou on ajoute un dépôt tiers pour la sécurité, solution qui devrait être adoptée pour Debian CUT si le projet aboutit).
[0] qui n’a été affecté ni par le bug Debian dans le générateur de nombres aléatoires, ni par celui-ci et dispose de dépôts de sécurité propres. Certaines failles surviennent évidemment en « stable » aussi, mais le niveau général de sécurité de cette distribution est incomparablement meilleur que les autres branches, voire que beaucoup de distrib’s.