Tu parle de “/var/cache/apt/” ou du fameux cache en mémoire ?
L’un je ne vois pas en quoi il risque de faire planter et le second il est (ou devrait en tout cas) réinitialisé avec un update.
oui, je parle de /var/cache/apt ou tu va trouver toutes les versions des paquets à la fin de la manip.
Ensuite, le changement de distrib est un changement de version sur des lots de paquets, et il peut toujours y avoir un risque sur chaque paquet, même s’il est faible, que ça plante. Pourquoi veux tu faire cette même opération de changement de versions deux fois ? Quel interet ?
L’intégrité du système au cas où tu as mal pingué par exemple et qu’un paquet important ne puisse pas fonctionner avec une nouvelle version.
Mais c’est vrai qu’en y réfléchissant de plus pres ce n’est pas forcément très intelligent.
? 
?
[quote="…"][quote=“teych”]En règle générale, pour le moment, il y a moins de problèmes en unstable qu’en testing, principalement parce que depuis le passage de Etch en stable, Lenny tarde à prendre sa vitesse de croisière.[/quote] ? ?[/quote] Il y a une palanqué de fils ou c’est expliqué. Qu’est ce qui te choque ?
Mouai… Il y a une pléiade de fils dans lequel c’est expliqué, et moi je n’ai toujours pas compris pourquoi… 
[size=85]NB: je comprends vite mais il faut m’expliquer longtemps[/size]
dommage.
Bon allez. Comme il n’y a pas de fil actif, je vais t’aider à comprendre.
Connais tu la différence entre stable, testing, et unstable, ainsi que le cycle de vie de la testing ?
As tu lu:
fr.debian.org/releases/
fr.debian.org/doc/FAQ/ch-ftp … #s-testing
et surtout
fr.debian.org/doc/FAQ/ch-ftp … s#s-frozen
?
Peux tu me résumer ce que tu as compris ?
Le fait que justement il y est une palanquée de fils sur ce forum qui affirment, et non expliquent cela.
La stabilité générale de Sid et Testing varie en permanence mais Lenny à trouvé sa « vitesse de croisière » depuis un moment déjà.
De plus je trouve beaucoup plus simple de remédier aux petits problèmes que l’on peut éventuellement avoir avec Testing qui sont d’ailleurs, chez moi, quasi inexistant depuis plusieurs mois, contrairement à ma Sid…
Maintenant ce n’est que mon point de vue… 
Fallait pas te déranger, mais merci pour ta patience.
Cela dit, je n’apprends pas grand chose de nouveau.
La version testing est une version qui évolue avec le temps : nouveaux paquets, nouvelles versions de paquets, corrections de bugs… Dès que la version est relativement mature elle commence à être partiellement gelée : elle évolue moins, seul les correctifs (bug et sécurité) corrigent la version. Puis elle finit par être totalement gélée. Et à ce moment là seulement, elle mérite son nom. Après sa mise en quarantaine, elle est déclarée stable.
Certes. Seulement actuellement, la testing, elle en est où ? Est-elle :
Chaude ? Froide ? Gelée ?
Dois-je comprendre que celle-ci n’a toujours pas commencé à être gelé ? Qu’elle contient encore beaucoup de bugs, dont les correctifs n’existent pour l’instant qu’en version unstable (ces paquets n’ayant pas encore passé la batterie de tests pour pouvoir être accepté dans la version testing) ?
Le fait que Lenny soit actuellement plus bugué que Sid serait alors un hasard ? Ce serait dû fait que le développement de nouvelle version de paquets va plus vite que leur “stabilisation” ?
quote="…"
Maintenant ce n’est que mon point de vue… [/quote]Ah ?
Alors il me semble que tu as de la chance, parceque les disparitions soudaines de séries de paquets continuent à arriver (la semaine dernière, j’ai justement remarqué en regardant les policies de deux trois trucs toute une série de disparition de paquets importants pendant quelques jours - je précise tout de suite que je n’ai plus la moindre idée desquels), et j’observe que les problêmes liés à l’absence de ceci ou de cela en Lenny continuent à poser des problêmes de mise à jour ou d’installation régulièrement dans “support debian”.
Maintenant, c’est certain que n’ayant plus que des machines en etch ou en sid, je ne suis pas le mieux placé pour en parler. Je vais recommencer à observer avant de continuer à tapper sur Kenny… Euh, je veux dire Lenny.
quote="Cver1"
Certes. Seulement actuellement, la testing, elle en est où ? Est-elle :
Chaude ? Froide ? Gelée ? [/quote]Bon OK mille excuses à tous les deux, je m’attendais trop à devoir répèter une fois de plus les raisons de l’instabilité d’une testing en début de cycle. [quote=“Cver1”]
Dois-je comprendre que celle-ci n’a toujours pas commencé à être gelé ? Qu’elle contient encore beaucoup de bugs, dont les correctifs n’existent pour l’instant qu’en version unstable (ces paquets n’ayant pas encore passé la batterie de tests pour pouvoir être accepté dans la version testing) ?[/quote] Ca, de toutes façons, le gel est encore loin, mais sinon, ça mériterait peut être de réflechir à un systême perso d’évaluation collective de la stabilité générale de la testing. [quote=“Cver1”]Le fait que Lenny soit actuellement plus bugué que Sid serait alors un hasard ? Ce serait dû fait que le développement de nouvelle version de paquets va plus vite que leur “stabilisation” ?[/quote] C’est ce qui me semble encore. Je ne sais pas si la vitesse de progression des softs gnus est actuellement en augmentation, mais si c’est le cas et que c’est une tendance stable, on arrive peut être aux limites du systême de qualification/intégration/gel du processus de stabilisation de debian.
Moins on change, mieux ça va 
Etch, parce que ça roxe
Sur mon PC:
- une etch pour le travail : je veux avoir une système sans histoire
- et une sid car certains paquets sont indisponibles en etch et par curiosité
- un win$ car certains logiciels du boulot ne fonctionnes pas avec wine et que le multiboot est plus simple que la virtualisation
Sur une autre PC, sid uniquement.
Avec un seul choix, je suis bien embêté …
C’est vrai pas de lenny pour l’instant …
Je ne peux pas non plus répondre au sondage car j’ai les trois et si tu te poses la question du choix, je te conseille de faire comme moi.
Tu as bien un DD de 40 GO au moins ? alors :
5 partitions :
swap = 1Go
/—etch = 5Go
/—lenny = 5Go
/—sid = 5Go (ou un peu + éventuellement)
/home commune = 'le reste dispo’Go
Ainsi, m^ si tu as des problèmes après une upgradation aventureuse, tu pourras patienter ou réparer tt en n’étant pas privé d’une Debian.
Lorsque j’ai commencé à utiliser Debian, voilà ce que j’ai lu un peu partout :
-Stable : C’est stable, c’est sûr, sans bug. Mais avec le temps les paquets deviennent obsolètes. Recommandée pour les serveurs.
-Testing : elle convient mieux à un usage “poste de travail”. Les paquets sont plus récents et moins de risques de bug car ce sont des paquets qui viennent d’unstable et qui n’ont pas révélé de problèmes. Donc ils peuvent aller tranquillement dans Testing
-Unstable : ouh là là !!! réservé aux pros, aux développeurs, aux aventuriers !! Vous aurez des problèmes très souvent, il faut que vous soyez trèèèès expérimentés !!!
Maintenant, mon avis perso d’après ma petite expérience et après lecture des liens qu’a indiqué mattotop :
Les versions Testing et Unstable ne se suffisent pas à elle-même. Je m’explique : si on décide d’être en Testing, n’avoir que les dépôts de testing ne suffit pas. J’ai eu parfois (souvent ?) ma Testing “cassée” car il arrive parfois (souvent ?) que des paquets migrent d’unstable vers testing mais que ces mêmes paquets aient besoin de dépendances se trouvant encore en unstable.
Et c’est pareil pour Unstable, il m’est arrivé de vouloir installer un programme se trouvant dans les dépôts d’unstable mais dont une dépendance se trouvait déjà en testing.
Il m’est déjà arrivé la chose suivante : j’avais gnome et xfce d’installé avec juste comme dépôts les dépôts testing. Lors d’une upgrade, apt m’a désinstallé gnome pour raisons de dépendances insatisfaites. Ne me restait plus qu’xfce. Ceci n’est qu’un exemple parmi tant d’autres.
Ce genre de souci a complètement disparu le jour où je me suis décidé à mettre les dépôts stable, testing et unstable dans mon sources.list avec un fichier preferences “qui va bien”. En effet depuis que j’ai fait celà, lorsqu’il arrive ce genre de souci de dépendances, aptitude sait automatiquement où piocher les bons paquets.
C’est pourquoi je pense qu’unstable et testing se complètent.
Pour conclure, et après lecture de la doc qu’à indiqué mattotop :
Je pense que la version stable se suffit à elle-même. Aucun souci de dépendances. Aucun bug. Le souci (qui n’en est pas vraiment un suivant ce que l’on recherche) c’est qu’avec le temps les paquets deviennent un peu anciens. Les nouveaux paquets n’y sont pas intégrés. Parfaite pour un serveur en production.
La version testing est une version de transition. C’est la future stable. Pas très intéressante. Il faut absolument avoir dans son sources.list les dépôts unstable et etch pour qu’il y ait le moins de bug possibles.
La version unstable n’est vraiment instable que si il elle est seule dans les dépôts. Avec un “sources.list au carré” complet (unstable + testing + etch) et un bon fichier preferences, c’est AMA avis la version la plus complète et la plus à jour qui convient le mieux à une station de travail moderne. Ce n’est pas la version pour les aventuriers comme je le lis trop souvent. Car apt est vraiment un outil qui a été bien pensé. Il arrive quand même qu’un bug arrive. Il suffit bien souvent d’une mise à jour pour que le prb soit résolu.
Au fait, j’en profite pour poser une question. Quand on a mis les 3 dépôts, y a-t-il un intérêt à mettre un fichier préférences, sauf si l’on veut par exemple que le 2nd choix après les paquets issus de Sid, soit les paquets issus de Etch? Car si je ne mets pas de fichier préférences, donc je me retrouve par défaut avec Sid>Lenny>Etch, c’est bien ça?
Concretement, oui, parceque les versions des paquets sont dans cet ordre, mais théoriquement, si pour une raison de mauvaise organisation une version testing se trouvait avoir un numéro superieur à une version sid, alors, sans preferences, c’est la version testing qui serait choisie.
Sid parce que je le vaux bien !
oki merci mattotop