Re: Méthode de stabilisation des release Debian en question...
Bonjour à tous les utilisateurs et développeurs de Debian :
Dans son message du 10/03/13 à 10:47, Maderios a écrit :
> La stable qui stagne pendant 2 ans pose des problèmes.
> Exemples vécus (liste non exhaustive)
> - quand elle ne suit pas l'évolution du matériel
> - quand certains paquets sont complètement dépassés par des versions
> plus performantes.
A mon avis, c'est, avant tout, un choix entre les versions "stable", "testing", "unstable" voire "experimental" pour les plus aventureux (euh très peu pour moi :-( ou alors, peut-être un jour, dans le cadre d'un machine virtuelle avec VirtualBox).
Comme cela est expliqué dans la FAQ Debian GNU/Linux (voir la page http://www.debian.org/doc/manuals/debian-faq/ch-choosing.fr.html#s3.1 ), concernant les "qualités" et les "défauts" de chaque version, on pourrait schématiser de la façon suivante (du moins c'est ainsi que je comprends) :
Stable >> Testing >> Unstable >> Experimental
Plus sûre >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Moins sûre
Moins déboguée >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Plus déboguée
Plus ancienne >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Plus récente (a)
Moins compatible >>>>>>>>>>>>>>>>>>>>>>>>> Plus compatible (b)
Et on pourrait énumérer éventuellement d'autres qualités ou défauts. ;-)
(a) Je parle des logiciels que peut proposer une telle version.
(b) Ici, il s'agit des composants internes (processeur, mémoire de masse, carte graphique,...) ou des périphériques externes (écran, imprimante, scanner,...) pris en charge par une telle version (de façon plus ou moins... optimisée mais cela est un autre débat).
A partir de là, chacun fera son choix en fonction de ses besoins et des ses souhaits et, surtout, en connaissance de cause.
Pour le reste et pour en revenir au débat initial, je continue à penser tout à fait pertinent le choix de Debian qui consiste (en gros) :
- (1) à gérer les 4 (ou même 5 si on ajoute "oldstable") versions de manière différenciée en fonction de leurs objectifs,
- (2) à décider si un paquet (selon sa propre version) peut entrer dans une version (autre que Stable) en fonction de la conformité de ses exigences que notre distribution préférée (dont certains jugeront un rien perfectionniste) s'est elle-même fixée et
- (3) à juger si Testing (et, avec elle, les milliers de paquets ce qui démontre, entre autres, toute la difficulté de la tâche) peut devenir, à un moment donné, la nouvelle Stable si elle remplit les critères de qualités qui convient à cette version... quitte à attendre plus de 6 mois (ou même plus de 2 ans ;-) ).
> - quant certains bugs ne sont pas corrigés alors qu'ils le sont dans les
> dernières versions des logiciels.
Euh, je ne sais pas trop de quels bugs tu veux parler (même si je ne conteste pas leur existence vu que j'intègre les mises à jour de sécurité pour ma Stable tous les lundis matin quand il y en a) mais, là encore, les bugs contenus dans Experimental, Unstable ou Testing (du moins avant sa période de gel et encore c'est à vérifier) sont, probablement, plus nombreux et moins anodins que ceux de Stable. :-|
> - dimension souvent ignorée: on peut facilement attendre 2 ans quand
> l'on est âgé de 25 ou 30 ans. A 60 ans, on tique fortement. Et à 80
> ans, cela n'a certainement plus de sens......
Quel que soit l'âge qu'on a, la patience est une des plus belles vertues, même pour les mortels comme nous... :-D
Cordialement et à bientôt,
Stéphane.
Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net
Reply to: