si tu ouvres un ticket chez redhat ou un vendeur tiers, la première chose qu'ils vont te demander de faire, c'est une update des paquets et reproduire le problème.
Oui, parce qu'on sait jamais si le probléme n'est pas déjà corrigé. Beaucoup de gens font pareil sur les projets libres en général, et ça n'a rien à voir avec la compatibilité, juste l'envie de ne pas perdre de temps sur ça.
Et en pratique, quand un programme tierce marche sur une distro X à un moment T et pas le lendemain d'une mise à jour, les clients râlent d'abord sur le dernier truc qui a changé en disant "vous avez cassé quelque chose". Et parfois, tu découvres que le logiciel dépend d'un comportement qui a en effet changé, mais qui n'était pas spécifié (et qui ne fait pas parti de l'ABI). Ou qui dépend d'un bug de sécurité, comme j'ai eu le cas ce matin avec woodpecker (j'ai un peu honte de ça).
la majorité des boites qui utilisent du redhat / centos utilisent des solutions comme redhat satellite/foreman pour avoir des snapshots des repos à un instant T et procèdent en général à du patching par lots, ce qui fait que toutes leurs machines vont souvent être à un même niveau de patch à tout instant.
Mais ça veut juste dire que tu as les mêmes paquets installés sur ton parc, pas que tu as les mêmes que le parc du voisin, ni le parc utilisé par les tests à un moment T par les vendeurs tierces ou les testeurs de RHEL. Ni même qu'ils ont été installés dans le même ordre ou au même moment.
Les installations de paquets ne sont pas déterministes, car l'ordre d'installation n'est pas forcément garanti (vu que les structures sous jacentes ne le sont pas forcément), et si des scripts de post installations sont impliqués, c'est encore pire.
C'était sauf erreur de ma part la conclusion d'un travail de recherche présenté lors d'une conférence en 2010 au FOSDEM, ou le présentateur a expliqué tout les soucis qui découlent d'avoir bash ou lua pour des scripts. Il est revenu l'année après avec une solution ou il remplace les scripts par un DSL d'actions limités et réversibles.
Et en fait, même la date d'installation du serveur peut jouer.
Les devs Openstack du bureau m'ont raconté un jour un bug épique. Je n'ai pas le détail, mais le contournement est détaillé ici. Le client avait fait les upgrades de tout son cluster depuis plusieurs versions, et à un moment, ça n'a pas marché. La QA n'a pas réussi à reproduire, on voyait bien que c'était un souci vis à vis de docker et du filesystem, mais c'est tout.
La solution est venu quand quelqu'un a tenté de refaire exactement le même parcours que le client (donc 6 ou 7 upgrades d'affilés) et a réussi à reproduire le souci. Et en effet, l'équipe QA a découvert que les partitions XFS déployéees en RHEL 7.0 n'était pas compatible avec ce que demande Docker (qui avait besoin d'overlayfs, qui a besoin d'autres choses, etc). L'intégration de docker a impliqué de faire un backport d'une fonction spécifique de XFS, fonctionnalité activé par défaut à l'installation des nouvelles versions (donc > RHEL 7.3) mais fonctionnalité manquante sur les serveurs du client car installés il y a trop longtemps (en 7.0).
C'est un cas extrême, mais ça montre bien qu'avoir exactement les mêmes binaires, ça peut ne pas suffire.
Et je suis sur que des cas comme ça (mais moins épique), mes collègues ont du en croiser souvent (moi, j'ai juste des bugs de merde comme le jour ou les tests de Gluster ont échoués car j'ai relancé Jenkins et le serveur a basculé en francais).
Et je parle pas des bugs dépendant du hardware, ou ce genre de trucs.
La compat bug pour bug, ça n'a aucun sens quand les bugs peuvent venir de partout en pratique.
[^] # Re: ça bouge, ça évolue
Posté par Misc (site web personnel) . En réponse à la dépêche L'affaire des sources : mémo des clones de Red Hat Entreprise Linux (RHEL). Évalué à 4.
Oui, parce qu'on sait jamais si le probléme n'est pas déjà corrigé. Beaucoup de gens font pareil sur les projets libres en général, et ça n'a rien à voir avec la compatibilité, juste l'envie de ne pas perdre de temps sur ça.
Et en pratique, quand un programme tierce marche sur une distro X à un moment T et pas le lendemain d'une mise à jour, les clients râlent d'abord sur le dernier truc qui a changé en disant "vous avez cassé quelque chose". Et parfois, tu découvres que le logiciel dépend d'un comportement qui a en effet changé, mais qui n'était pas spécifié (et qui ne fait pas parti de l'ABI). Ou qui dépend d'un bug de sécurité, comme j'ai eu le cas ce matin avec woodpecker (j'ai un peu honte de ça).
L'exemple connu, c'est ce vieux bug avec flash et la glibc: https://bugzilla.redhat.com/show_bug.cgi?id=638477 .
Le cas de Windows 95 et Simcity est un autre exemple connu, il a encore été cité en 2022.
Mais ça veut juste dire que tu as les mêmes paquets installés sur ton parc, pas que tu as les mêmes que le parc du voisin, ni le parc utilisé par les tests à un moment T par les vendeurs tierces ou les testeurs de RHEL. Ni même qu'ils ont été installés dans le même ordre ou au même moment.
Les installations de paquets ne sont pas déterministes, car l'ordre d'installation n'est pas forcément garanti (vu que les structures sous jacentes ne le sont pas forcément), et si des scripts de post installations sont impliqués, c'est encore pire.
C'était sauf erreur de ma part la conclusion d'un travail de recherche présenté lors d'une conférence en 2010 au FOSDEM, ou le présentateur a expliqué tout les soucis qui découlent d'avoir bash ou lua pour des scripts. Il est revenu l'année après avec une solution ou il remplace les scripts par un DSL d'actions limités et réversibles.
Et en fait, même la date d'installation du serveur peut jouer.
Les devs Openstack du bureau m'ont raconté un jour un bug épique. Je n'ai pas le détail, mais le contournement est détaillé ici. Le client avait fait les upgrades de tout son cluster depuis plusieurs versions, et à un moment, ça n'a pas marché. La QA n'a pas réussi à reproduire, on voyait bien que c'était un souci vis à vis de docker et du filesystem, mais c'est tout.
La solution est venu quand quelqu'un a tenté de refaire exactement le même parcours que le client (donc 6 ou 7 upgrades d'affilés) et a réussi à reproduire le souci. Et en effet, l'équipe QA a découvert que les partitions XFS déployéees en RHEL 7.0 n'était pas compatible avec ce que demande Docker (qui avait besoin d'overlayfs, qui a besoin d'autres choses, etc). L'intégration de docker a impliqué de faire un backport d'une fonction spécifique de XFS, fonctionnalité activé par défaut à l'installation des nouvelles versions (donc > RHEL 7.3) mais fonctionnalité manquante sur les serveurs du client car installés il y a trop longtemps (en 7.0).
C'est un cas extrême, mais ça montre bien qu'avoir exactement les mêmes binaires, ça peut ne pas suffire.
Et je suis sur que des cas comme ça (mais moins épique), mes collègues ont du en croiser souvent (moi, j'ai juste des bugs de merde comme le jour ou les tests de Gluster ont échoués car j'ai relancé Jenkins et le serveur a basculé en francais).
Et je parle pas des bugs dépendant du hardware, ou ce genre de trucs.
La compat bug pour bug, ça n'a aucun sens quand les bugs peuvent venir de partout en pratique.