On Tue, 2014-11-11 at 09:50 +0100, Thierry de Coulon wrote: > J'adore Debian, mais la version stable pose souvent des problèmes en "fin de > vie", comme maintenant: certains applications ont besoin de nouvelles > librairies, il faut incorporer des bouts de testing... et il arrive que la > mise à jour devienne impossible.
Bonjour, Tout dépend de ce qu'on appelle des "bouts" de testing. Si c'est une ou deux applications qui tirent peu de dépendances, et gérées dans APT avec le pining (je l'ai fait pour firefox par exemple, enfin iceweasel). Alors ça se passe relativement bien. Mais il est préférable de chercher dans les "backports" (voire de recompiler le deb-src si ça passe facilement) avant de se lancer dans un mix stable+testing. Ou mieux, utiliser la testing directement. > Par ailleurs, est-ce qu'on peut vriament faire une mise à jour d'une Debian 5 > à une Debian 7 sans problème? Je n'ai pas essayé de mettre à jour une SuSE à > chaque coup, mais ici l'OP veut passer d'une 11 à une 13, et il s'est passé > beaucoup de choses entre deux (bon, il doit s'être écoulé moins de temps > entre deux versions principales que chez Debian...) La procédure recommandée est toujours la suivante: - mettre à jour la distribution dans sa version actuelle - le dépôt peut avoir été déplacé dans "archives.debian.org", donc il faut éditer la source APT - faire l'upgrade vers chaque version majeure en incluant les dernières mises à jour, dans ton cas 5 -> 6 -> 7 - à chaque étape, vérifier les fichiers ".dpkg-old" et ".dpkg-new" ou encore ".ucf-old" et ".ucf-new" qui indique des conflits lors d'éditions dans /etc Si par contre, la configuration des services a uniquement été faite par les masques de Debconf (dpkg --reconfigure paquet), alors même les mises à jour les plus tordues (comme MySQL) passent souvent tout seul. J'en profite pour signaler qu'il est important de configurer en ajoutant des fichiers dans les répertoires ".d" comme /etc/sysctl.d/ /etc/apt/sources.list.d/ /etc/apt/preferences.d/ /etc/mysql/conf.d /etc/sudoers.d/ (même si des tuto ou des blogs ne les mentionnent que rarement !!) pour s'épargner justement les reports de clefs de configuration (.dpkg-old et .dpkg-new) dans les fichiers principaux gérés par les paquets. Et bien sûr, quand il s'agit d'un serveur, le moins de paquets sont installés, le mieux c'est, pour la sécurité, mais aussi pour les ugprades. > Moi, même avec Debian, je tourne "à la japonaise": pour les grands temples, > ils construisent le nouveau pendant qu'ils utilisent l'actuel, puis ils > changent de temple et reconstruisent l'ancien à neuf. > Moi j'ai une distribution que j'utilise. QUand je veux passe à une nouvelle, > je l'installe au propre à côté, je transfère progressivement les > configurations. C'est seulement une fois la nouvelle configuration rodée que > je peux écraser la "vielle" distribution. Pourquoi pas, mais c'est vraiment un travail inutile quand il s'agit d'une Debian gérée correctement / proprement. Perso, je fais souvent des clones de VM ou de système avec des copies rsync lorsque je veux changer les partitions, avant de tester et valider la procédure d'upgrade. Si certaines configurations ne sont plus compatibles, cela me laisse le temps de chercher et documenter, avant d'appliquer l'upgrade en production. > J'ajoute que je ne mets pas mes données importantes dans "home", elles sont > sur une autre partition, jamais touchée lors de l'installation - libre à > l'utilisateur de faire un lien dans home, évidemment. Si "home" est un système de fichiers indépendant, il n'y a aucune raison de ne pas l'utiliser "tel quel", c'est quand même plus confortable. Par précaution, il m'arrive de démonter "/home" avant le "apt-get dist-upgrade", pour éviter des bricoles inattendues, même avec des backups tout frais dûment vérifiés. Pour conclure, les upgrades Debian de versions stables passent normalement comme une lettre à la poste, si le système est géré avec rigueur et précautions (j'ai appris ça sur le temps, upgrade après upgrade). Pour un poste de travail, utiliser la "testing" présente souvent peu de risque de "crash" gênant (mais jamais définitif) et permet d'avoir un système "toujours à jour", en fonction du rythme d'update que l'on choisit (par mois ou par trimestre). En espérant avoir motivé de nouveaux adeptes -- Yves Martin _______________________________________________ gull mailing list [email protected] http://forum.linux-gull.ch/mailman/listinfo/gull
