Cool ce freeze 
Je reste persuadé que geler squeeze en plein été n’est pas une idée des plus brillantes… 
[quote=“dric64”]Je reste persuadé que geler squeeze en plein été n’est pas une idée des plus brillantes… [/quote]De mon côté en Bretagne elle ne risque pas de fondre même en été 
L’été ce n’est que pour la moitié de la planète 
Dans 6 mois en stable ? cadeau de noël…
Donc si j’ai bien compris la Sid reste la Sid, la Squeeze deviendra la stable (lorsque l’équipe de management Debian l’aura décidé), et entre les deux sera créée une nouvelle “testing” avec un nom peut-être connu, ou pas encore connu, et de nouveaux dépôts correspondants.
Exact ?
[quote=“taureau89_9”]
Donc si j’ai bien compris la Sid reste la Sid, la Squeeze deviendra la stable (lorsque l’équipe de management Debian l’aura décidé), et entre les deux sera créée une nouvelle “testing” avec un nom peut-être connu, ou pas encore connu, et de nouveaux dépôts correspondants.
Exact ?[/quote]
Si c’est écrit Lenny dans ton sources.list, tu resteras sous Lenny.
Si c’est écrit Stable, tu passeras de Lenny à Squeeze le moment venu.
Si c’est écrit Squeeze, tu resteras sous Squeeze quand elle sera stable.
Si c’est écrit Testing, tu resteras en testing, qui recevra un nom et un numéro de version, et tu assisteras à un déferlement de paquets en provenance de la sid, qui aura continué à évoluer pendant le gel de la testing.
Si c’est écrit Sid ou Unstable (c’est la même chose), tu restes sous Sid.
Si aucune de ces perspectives ne te convient, il te faudra modifier ton sources.list
Ah que voilà une explication claire, merci.
Je ne pensais pas du tout que ça marchait comme ça.
Car en effet je m’étais fié au topic de trucs et astuces sur le sources.list au carré, mais qui ne parle que de lenny, squeeze et sid…
Donc actuellement je suis en lenny et en squeeze.
Suffit-il donc que dans le sources.list, partout où il y a lenny je marque stable, et partout où il y a squeeze je marque testing si je veux évoluer en restant sous ces deux installations ?
Tout dépend.
Si tu est en stable, tu peux mettre “stable” à la place des noms de distribution.
Si tu es en testing, je te conseille de laisser nominativement le nom de la version et d’attendre avant de passer à la nouvelle version en testing. Les premiers mois sont toujours difficile dans le cas contraire… j’étais passé en sid pour plus de stabilité la première fois que je me suis fait surprendre de cette façon ^^
Il y’a souvent tout un tas de paquet qui passent de sid à testing à cette période, mais pas forcement certains paquets dont ces nouveau paquet dépendent, du coup ca cause de gros bordel de dépendances non satisfaites. J’ai cru comprendre que je n’étais pas une exception et que ce genre de problème arrive fréquemment lors des changements de version.
Étant sous Squeeze, j’ai l’intention d’y rester quand elle sera stable, quitte à faire, au besoin, des emprunts limités dans les dépôts sid et, si nécessaire, dans des dépôts exotiques.
J’ai ajouté les dépôts sid dans le sources.list et créé un fichier apt.conf contenant : APT::Default-Release "squeeze";
J’espère que ça va marcher et que je n’aurai pas besoin de me prendre la tête avec un fichier preferences.
[quote=“Blacksad”]Tout dépend.
Si tu est en stable, tu peux mettre “stable” à la place des noms de distribution.
Si tu es en testing, je te conseille de laisser nominativement le nom de la version et d’attendre avant de passer à la nouvelle version en testing. Les premiers mois sont toujours difficile dans le cas contraire… j’étais passé en sid pour plus de stabilité la première fois que je me suis fait surprendre de cette façon ^^
Il y’a souvent tout un tas de paquet qui passent de sid à testing à cette période, mais pas forcement certains paquets dont ces nouveau paquet dépendent, du coup ca cause de gros bordel de dépendances non satisfaites. J’ai cru comprendre que je n’étais pas une exception et que ce genre de problème arrive fréquemment lors des changements de version.[/quote]
Donc tu me confirmes que dans mon sources.list de lenny je peux mettre stable à la place de lenny; et que dans le sources.list de ma squeeze je peux mettre testing à la place de squeeze.
Mais dans le second cas tu me conseilles plutôt d’attendre quelque temps que ce soit stabilisé, à moins que je n’aie pas peur de prendre quelques risques (qui ne devraient pas être si gênants puisque j’ai et je tiens à garder une stable).
Salut,
[quote=“taureau89_9”]…
Donc tu me confirmes que dans mon sources.list de lenny je peux mettre stable à la place de lenny; et que dans le sources.list de ma squeeze je peux mettre testing à la place de squeeze.
Mais dans le second cas tu me conseilles plutôt d’attendre quelque temps que ce soit stabilisé, à moins que je n’aie pas peur de prendre quelques risques (qui ne devraient pas être si gênants puisque j’ai et je tiens à garder une stable).[/quote]
Si tu tiens à garder une stable, je te conseillerais de laisser Lenny dans ton sources.list, le temps de voir si le passage de Lenny à Squeeze (quand elle sera définitivement déclarée stable) ne pose pas trop de problèmes.
Pour ma part, sur un serveur en production, je ne prend pas de risques. Enfin… pas trop 
Au pire, le moment venu, faire un clone et tenter un dist-upgrade sur celui-ci 
C’est parce que dorénavant les cycles de freeze se feront selon des dates précises (tous les 2 ans), donc ils en ont fait un plus court que d’habitude cette fois-ci pour s’aligner sur la date de freeze future.
Sinon je suis actuellement en Sid et je tourne avec le noyau 2.6.32-5 (64 bits). Est-ce que vous savez si le 2.6.34 fera partie de Squeeze ? Car ce noyau apporte de sacrés changements en termes de performance et ça m’embêterait énormément de devoir utiliser la prochaine Sid juste pour avoir accès à ce noyau… S’ils l’incluent dans Squeeze je pourrai enfin avoir une distribution en Stable à utiliser quotidiennement !
C’est d’ailleurs logique, si ca vient de freezer avec un noyau 2.6.32 c’est que le noyau sera un 2.6.32. Mais il y aura des backports.
De ce que j’ai pu tester des backports, je préfère encore 10 fois plus passer en Sid… Au moins la Sid fonctionne !
C’est vraiment dommage que le freeze n’intègre pas le kernel 2.6.34 quand on voit ce qu’il apporte 
De ce que j’ai pu tester des backports, je préfère encore 10 fois plus passer en Sid… Au moins la Sid fonctionne !
C’est vraiment dommage que le freeze n’intègre pas le kernel 2.6.34 quand on voit ce qu’il apporte [/quote]
Faut pas generaliser, c’est pas de bol pour toi, mais je fonctionne avec des noyaux des backports sur toutes les lenny de la maison, jamais eu de problemes.
Installation toute fraîche d’une Lenny, puis rajout des backports dans le sources.list, installation du backport pour le noyau 2.6.x (je les ai tous testé) ==> le système fonctionnait mais vraiment très mal (luminosité qui n’était plus réglable, des erreurs de partout avec Gnome,…). Donc plus qu’un manque de bol, je pense que les backports ne sont qu’éventuellement une solution temporaire pour remédier à un problème spécifique, rien de plus.
Je précise que je tourne avec la version 64 bits, ça peut grandement jouer à mon avis.
Installation toute fraîche d’une Lenny, puis rajout des backports dans le sources.list, installation du backport pour le noyau 2.6.x (je les ai tous testé) ==> le système fonctionnait mais vraiment très mal (luminosité qui n’était plus réglable, des erreurs de partout avec Gnome,…). Donc plus qu’un manque de bol, je pense que les backports ne sont qu’éventuellement une solution temporaire pour remédier à un problème spécifique, rien de plus.
Je précise que je tourne avec la version 64 bits, ça peut grandement jouer à mon avis.[/quote]
Oui je comprends bien que ce soit genant, mais une fois de plus je n’ai pas eu ces problemes, en 64 bits comme en 32 bits et sur plusieurs ordinateurs differents.
Quoi qu’il en soit, il est toujours possible de compiler son propre noyau aussi.
Installation toute fraîche d’une Lenny, puis rajout des backports dans le sources.list, installation du backport pour le noyau 2.6.x (je les ai tous testé) ==> le système fonctionnait mais vraiment très mal (luminosité qui n’était plus réglable, des erreurs de partout avec Gnome,…). Donc plus qu’un manque de bol, je pense que les backports ne sont qu’éventuellement une solution temporaire pour remédier à un problème spécifique, rien de plus.
Je précise que je tourne avec la version 64 bits, ça peut grandement jouer à mon avis.[/quote]
Oui je comprends bien que ce soit genant, mais une fois de plus je n’ai pas eu ces problemes, en 64 bits comme en 32 bits et sur plusieurs ordinateurs differents.
Quoi qu’il en soit, il est toujours possible de compiler son propre noyau aussi.[/quote]
marrant (?) que je soie le seul a avoir fait 3 tentative en 64 et que chaque foi sa parte en vrille … sur 3 machine don 2 portable … bref le souci a la base c est le matériel. on ne trouve pas du matériel rescent libre performant. par 3 fois les driver video était en cause évidement propriétaire…
Cela à changer quand j’ai pris le problème autrement:
[gné?]avec la force le roseaux va plier,plutôt que de casser 
(…)[\gné]
Vu le choix des paquet, vu le nombre, je me suis dit en gros:
sa plante c est lourd bref sa casse(gné),j’ai virer gnome/kde et pris des paquet qui son dans la mesure du possible pas trop “moche” et pas trop “lourd”
j’ai fait une liste des paquet par priorité. compiler mon propre kernel installer le tout et sa tourne nikel …
faire les mise a jours seulement après avoir fait une sauvegarde (même principe que M$ sauf qu’on peux enfin savoir a quel moment le faire)
On peux donc dire que c’est contourner le problème (plier )
je pense que gnome/kde on tellement de dépendance que si un bug survient dans la chaîne sa plante ailleur…
Sous linux le principe.
Est en principe que chaque programme est spécifique a une tache ,avec les dépendances on rompt ce principe. 
le kernel joue un role c’est sure mai amha le problème vient sûrement de la petite bestiole qui ce promène sure la route des dépendances… comme certain fond mumuse avec le fichier préférences … car souvent on est obliger surtout quand c est pour les driver video(pour ne citer que cela…)
on ne fait pas du neuf avec du vieux… mélanger sid et stable = pas bon
bon je dit ça je dit rien 
[quote=“panthere”]
je pense que gnome/kde on tellement de dépendance que si un bug survient dans la chaîne sa plante ailleur…[/quote]
Oui j’ai l’impression que la plupart des personnes qui ont des problemes en testing/sid ou backports utilisent gnome/kde, etc… Avec un window manager leger n’impliquant pas des dependances compliquees ca a toujours roule pour moi. Faut quand meme faire gaffe a ce que l’ont fait, bien sur.
Pour les backports faut installer juste ce dont l’on a vraiment besoin pas plus.