[gull] Mise à jour Debian par étapes

Daniel Cordey dc at pxcluster.com
Mon Dec 22 13:26:53 CET 2025


On 12/22/25 12:43, Claude Paroz via gull wrote:
>
> Bah non, ce n'est vraiment pas mon expérience, ça fait plus de 15 ans 
> que je passe de LTS à LTS en Debian, et 98% du temps, ça se passe très 
> bien pour moi.
> Ça dépend certainement des cas d'utilisation, mais pour ma part, c'est 
> absolument satisfaisant.

Oui... 98%... Mais, justement, ces 2% peuvent te pourrir la vie. J'avais 
à gérer des serveurs pour les marchés financiers et une indisponibilité 
de 5 minutes était déjà très problématique. Donc, pas envisageable de 
dire "let's go and see...".


>
> Je crois que tu as manqué le *tant que les dépendances sont 
> respectées* dans ma question :) Il est tout à fait possible de 
> mélanger certains paquets de plusieurs versions Debian, pour autant 
> que le système de dépendances l'accepte (par ex. apt install <paquet> 
> -t unstable). Une telle commande va automatiquement "tirer" les 
> dépendances nécessaires.

Non, je n'ai pas zappé ce cas. Sauf que je trouve complètement aberrant 
de faire du LTS et ensuite de mélanger du testing avec. Je sais que 
certains sont adeptes de ces pratiques, mais c'est, de nouveau, à mon 
humble avis, un non-sens.  On veut du super-stable, mais on fait des 
exceptions... il faudrait savoir si on est maniaque sur la stabilité ou 
pas.

Les problèmes sont multiples. Ce peut être un problème de compatibilité 
de code (très rare), mais la grande majorité du temps, il s'agit de 
problème de formats ou de définitions dans les fichiers de configuration 
d'un package. Il peut aussi s'agir d'un problème de version de librairie 
utilisée par le package ; ce qui peut être compliqué, car certains 
packages utilisent des liens symboliques qui peuvent entrer en conflit 
entre les versions. Dans ces deux cas, mélanger deux versions me fait 
dresser les cheveux sur la tête. Même si cela peut fonctionner, on a 
alors complètement cassé l'objectif poursuivit par la notion de LTS et 
ça devient alors un enfer de sysadmin; le problème étant alors amplifié 
lorsqu'il faut ajouter/installer un patch corrigeant un bug ou un 
problème de sécurité. Ce que je dis est basé sur des années d'expérience 
dans un environnement très stressant et ne tolérant aucune panne. Il 
s'agit alors de trouver le meilleur compromis, et les versions LTS m'ont 
amené plus de problèmes qu'elles n'en ont résolus. Dans tous les cas, il 
est essentiel de pouvoir disposer d'un système de test (hors production) 
pour valider les changements à effectuer. Si tu plantes ton système de 
test, ce n'est pas grave. Mais faire de l'équilibrisme sur un système en 
production est plus que téméraire.

>
> Mon activité sysadmin est vraiment accessoire, et je veux y consacrer 
> le moins de temps possible.

Ce qui est aussi mon cas. J'ai toujours cherché à minimiser le temps 
passé à faire du sysadmin; en considérant que c'était un mal nécessaire. 
J'ai donc toujours cherché des solutions qui me permettaient de 
minimiser les problèmes. C'est ce qui m'a poussé à adapter mes pratiques 
et mes outils aussi vite que possible. C'est pour cette raison que je 
m'étais mis à OpenVZ bien avant LXC et Docker. Consacré du temps à ces 
changements de stratégie m'ont fait économiser du temps sur le long terme.

A+

dc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://forum.linux-gull.ch/pipermail/gull/attachments/20251222/64dbbf51/attachment.html>


More information about the gull mailing list