Re: Mise à jour Debian par étapes
Daniel Cordey via gull <gull-04vmY7CpswVinyhjFObuvR+/[email protected]> Mon, 22 Dec 2025 13:26:53 +0100
| Newsgroups | gmane.org.user-groups.gull.general |
|---|---|
| Message-ID | <[email protected]> |
--===============0359699044==
Content-Type: multipart/alternative;
boundary="------------GrSYj8eNlO4IcAr1cQWK7PaT"
Content-Language: es-ES, fr, en-US
--------------GrSYj8eNlO4IcAr1cQWK7PaT
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
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
--------------GrSYj8eNlO4IcAr1cQWK7PaT
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html data-lt-installed="true">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body style="padding-bottom: 1px;">
<p><br>
</p>
<div class="moz-cite-prefix">On 12/22/25 12:43, Claude Paroz via
gull wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0122b689-579a-4718-b0a4-8a06bb2fcae2-7lkl8Tipo3fR7s880joybQ@public.gmane.org"><br>
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.
<br>
Ça dépend certainement des cas d'utilisation, mais pour ma part,
c'est absolument satisfaisant. <br>
</blockquote>
<p>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...". </p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:0122b689-579a-4718-b0a4-8a06bb2fcae2-7lkl8Tipo3fR7s880joybQ@public.gmane.org"><br>
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. <br>
</blockquote>
<p>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. </p>
<p>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. </p>
<blockquote type="cite"
cite="mid:0122b689-579a-4718-b0a4-8a06bb2fcae2-7lkl8Tipo3fR7s880joybQ@public.gmane.org"><br>
Mon activité sysadmin est vraiment accessoire, et je veux y
consacrer le moins de temps possible. <br>
</blockquote>
<p>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.</p>
<p>A+</p>
<p>dc</p>
<pre class="moz-signature" cols="72">
</pre>
</body>
<lt-container></lt-container>
</html>
--------------GrSYj8eNlO4IcAr1cQWK7PaT--
--===============0359699044==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZ3VsbCBtYWls
aW5nIGxpc3QKZ3VsbEBmb3J1bS5saW51eC1ndWxsLmNoCmh0dHBzOi8vZm9ydW0ubGludXgtZ3Vs
bC5jaC9tYWlsbWFuL2xpc3RpbmZvL2d1bGw=
--===============0359699044==--