Testing ou sid, laquelle est la plus stable ?

Pause Café
#1

Je précise ma question, qui n’aurait pas tenu dans le titre.

Quand on veut des paquets plus récents qu’une stable, qui n’évolue que très peu en deux ans ou plus, que vaut-il mieux en termes de stabilité, testing ou sid ?

Et pourquoi vouloir des paquets plus récents qu’une stable ?

Car au bout d’un certain temps, certains paquets deviennent vraiment anciens, voire obsolètes.
Une stable, c’est suffisant pour 95% des utilisations, les classiques, bureautique, gestion d’images, etc…
D’ailleurs j’en ai une sur un DD, je ne suis donc jamais réellement en panne.

Mais je suis utilisateur du simulateur de vol Flightgear.
Dans les dépôts (que ce soit ceux de Debian, des Ouboutueux ou autres), il existe des paquets précompilés de FG.
Je ne les utilise jamais.
Car FG est une communauté de dev très active, et FG est constemment évolutif.
Les paquets précompilés sont toujours loin d’être à jour.
Donc je compile FG à partir des sources sur le GIT et j’ai donc toujours une version up to date.
(ou à peu près, car certains compilent tous les jours, pas moi, compte tenu de la vitesse de ma ligne adsl)
Or au bout d’un certain temps FG finit par ne plus compiler avec des paquets obsolètes.
Voilà pourquoi je ne suis pas en stable pour FG.

Quand je lis les avis du forum qui se présentent de temps à autre, ceux qui sont en testing disent que vu ce qu’ils lisent sur le forum concernant les problèmes que rencontrent ceux qui sont en sid, ils ne changeront sûrement pas.
Et ceux qui sont en sid avancent des arguments comme quoi une testing est une distribution qui sert aux développeurs pour tester une future stable, mais qui finalement est moins stable qu’une sid.

Alors, testing ou sid, laquelle est la plus stable ?

#2

Tu veux dire qu’on ne peut pas compiler FG sous stable au bout d’un certain temps ? Quels sont les paquets qui deviennent obsolètes vis à vis de la compilation de FG ? Sinon, pour répondre à ta question il faut mixer testing et sid avec une préférence (au sens fichier preferences) soit pour testing soit pour sid, au choix. Les corrections “upstream” arrivent plus vite dans sid que dans testing donc, sid semble instable mais moins longtemps par paquet tandis que testing est moins instable dans son ensemble (intégration des paquets en un tout cohérent, futur stable). Entre les deux, il reste le projet CUT (testing qu’on peut utiliser constamment) qui consiste à utiliser des clichés de testing relativement stable et de passer de l’un à l’autre. Voir les snapshots.

EDIT
J’oubliais, si on n’est pas pressé, une stable avec backports suffit largement. Quitte à créer les backports soi-même quand c’est possible.

#3

Il faut dire que Testing et Sid sont très semblables, par exemple sur ma sid j’ai au total 1466 paquets installés actuellement dont 1232 sont communs à Testing et Sid soit 84%.

J’ai les 2 dépots dans mon sources.list (testing et sid + experimental) quand je trouve des problèmes avec des paquets unstable je les descends en testing ; actuellement je n’ai qu’un seul paquet dans ce cas (pinné par apt-listbug)

#4

Oui, à une époque.
Maintenant je suis moins sûr car je ne suis plus en stable pour FG depuis environ 2 ans.
Ceci dit c’est plutôt à la fin de vie de la stable bien sûr, pas encore avec wheezy actuellement.

Alors là hélas depuis le temps je ne me souviens plus, mais plein !
(de mémoire entre autres il y avait les libboost, mais c’était pas les seuls).

#5

Chacune a les inconvénients de ses avantages. La testing ayant une cadence de mises à jours des paquets moins importante, lorsqu’un des paquets est buggué, il le reste plus longtemps en testing qu’en sid. Au contraire, lorsque tout ronronne parfaitement, il se peut que ca dure moins longtemps en sid qu’en testing pour la même raison (nouveau paquet --> risque de bug).

#6

Salut,

Réponse prudente :

Et si tu attendais d’avoir des ennuis de compilation pour revenir poser une question précise sur la manière de résoudre ce problème de compilation ?
Tu ne prendrais aucun risque pendant certainement plus d’un an et il sera toujours temps de nous occuper du problème quand çà se produira.
En attendant tu es en stable et çà fonctionne tousles jours de la même manière.
Laisse aux gens qui ont du temps à consacrer aux bugs, le soin de déméler les problèmes :laughing:

#7

testing n’est pas une distribution mais un outil de travail. En tant que telle elle est incomplète et a des mises à jour de sécurtié en retard. Elle ne peut être utiliser qu’en y rajoutant les paquets de sid ou de la stable courante.
À cette heure où la stable vient de sortir, il est illusoire de passer sur la testing, le mieux est de basculer sur sid ou sur la wheezy.
Enfin en ce qui concerne ton souci, il te suffit de faire les backports des bibliothèques nécessaires ou bien de faire un chroot sid au choix.

#8

Ok, merci pour vos réponses.

#9

+1

Surpris que personne n’ait mentionné les backports avant d’ailleurs. Avec ça tu peux récupérer une version plus récente des paquets qu’il te faut sans jouer avec le feu.

#10

Salut,

+1
Surpris que personne n’ait mentionné les backports avant d’ailleurs. Avec ça tu peux récupérer une version plus récente des paquets qu’il te faut sans jouer avec le feu.[/quote]

Ce n’est pas exactement ajouter le dépôt backports qu’indique François.
Il propose de “backporter” soit même les paquets dont on a besoin.

Jouer avec le dépôt backports (tout avec multimedia d’ailleurs) peut-être une grande source d’instabilité.

#11

La plus stable, je ne sais pas mais je n’ai pas les connaissances nécessaires pour administrer une version testing (pinning, rétropédalage dans les versions des paquets, tout ça…). Et pas envie de les acquérir donc Sid me convient mieux. Les quelques frayeurs que j’ai pu avoir participent aussi à mon apprentissage. :smiley:

#12

C’est vrai, moi aussi.

En fait j’ai mis la coche verte après avoir trouvé une réponse assez satisfaisante à ma question dans ce tuto.

De plus il est dit, je cite : De cette façon, nous espérons que « testing » soit une version toujours prête à la publication.

Autrement dit, une CUT, ça sert à rien, non ?

(bon c’est une grosse blague mais ça va faire réagir !)

#13

Pour ma part c’est ce que je fais plus ou moins. Je lance fréquemment des apt-get upgrade quand je rencontre des bugs mais je peux rester plus de six mois avec une testing pas à jour si le besoin ne se fait pas ressentir.

(vous avez le droit de me taper si vous jugez que ce déterrage de topic est inutile)

#14

Te taper, non, mais te rappeler qu’un système à jour est la meilleure garantie de ne pas naviguer sur une passoire, si :slightly_smiling:

#15

cut est “mort” depuis juillet 2012
parsix sur une base wheezy fait tourner des programme récents (gnome 3.10)

#16

Sur mes système un peu critiques (comprendre le routeur et les serveurs) je suis en stable et je mets régulièrement à jour, reboot pour le kernel et tout.
Pour un système perso, qui est derrière un firewall, je m’en soucis un peu moins.

#17

Tiens, puisqu’on en parle, vous êtes plutôt :

Testing, avec priorité sur stable, puis sid sur les paquets manquants:

Package: *
Pin: release a=testing
Pin-Priority: 900

Package: *
Pin: release a=stable
Pin-Priority: 900

Package: *
Pin: release a=unstable
Pin-Priority: 90

ou Testing, avec priorité sur sid, puis stable sur les paquets manquants:

Package: *
Pin: release a=testing
Pin-Priority: 900

Package: *
Pin: release a=stable
Pin-Priority: 700

Package: *
Pin: release a=unstable
Pin-Priority: 800

C’est quoi le mieux, en fait ?
:006

#18

Première solution pour moi !

#19

Première aussi …

#20

hmm ok, c’est aussi celle que j’ai, mais elle est un peu… ennuyeuse, il ne se passe pas grand chose, quand on vient d’une sid… :think: J’hésite à changer…