fix(appliance): purger les anciens noyaux au lieu de refuser l'image

[stephrobert]

Summary

Le build de l'appliance de la 0.3.0 a échoué, sur notre propre garde-fou :

plus d'un noyau installé : l'image serait inutilement lourde

Il avait raison sur le poids — deux noyaux pèsent 170 Mio bruts — et tort sur le geste : le correctif est mécanique, et refuser laisse une release sans appliance.

La cause

Debian a publié un noyau entre la gravure de l'ISO et ce build. Trois faits se combinent :

1. l'installateur pose son noyau explicitement, donc il n'est pas marqué « automatique » ;
2. apt-get autoremove --purge, au début du script, ne retire que les paquets automatiques : il ne le voit pas ;
3. le full-upgrade en installe un plus récent à côté.

Le script garde maintenant le noyau le plus récent — celui qui bootera — et purge les autres, y compris celui en cours d'exécution : il est en mémoire, et cette machine va s'éteindre juste après.

Le garde-fou reste, déplacé après le nettoyage : il porte désormais sur le résultat et non sur l'intention, et il nomme les fichiers restants quand il parle. C'est l'invariant du projet appliqué à lui-même — un contrôle vérifie ce qui est, pas ce qu'on a voulu faire.

Éprouvé hors de la VM, sur le piège qui compte

noyau gardé : 6.12.10+deb13-amd64      ← un tri alphabétique aurait choisi 6.12.9
cas à un noyau : 6.12.10+deb13-amd64   ← rien à purger, et la boucle se tait

sort -V et non sort : c'est exactement le genre de détail qui ne se voit qu'au build suivant.

Type of change

• Bug fix
• New feature
• Refactor
• Documentation
• Chore / tooling
• Security / supply chain

Checklist

Always

• uv run ruff check … passes — aucun code Python touché
• uv run mypy src/dsoxlab passes (strict)
• uv run pytest passes
• uv run pytest tests_e2e passes
• The engine stays domain-agnostic
• No hardcoded personal path or host
• Manually tested : bash -n sur le script, et la sélection du noyau jouée sur un /boot factice à deux entrées, dont le cas où le tri de version décide

When behavior changes

• Both CHANGELOG.md and CHANGELOG.fr.md updated — dans la section 0.3.0, et non dans une 0.3.1 : l'appliance de cette release n'a jamais été publiée, donc il n'y a rien à corriger du point de vue d'un utilisateur ; il y a une image à livrer
• Version bumped — N/A motivé : la 0.3.0 est déjà sur PyPI et sa Release existe. Le workflow Appliance sera relancé par workflow_dispatch avec tag: v0.3.0, ce que le workflow prévoit explicitement pour ce cas

When a command or option is added, removed or changed

• N/A.

When .github/workflows/ is touched

• N/A — le script packer/scripts/90-nettoyage.sh change, pas le workflow.

When the declarative contract changes

• N/A.

Ce qui se passe après le merge

Je relance Appliance avec tag: v0.3.0 : les images s'attacheront à la Release existante, sans nouveau tag. Puis je vérifie l'OVA publiée comme je l'ai fait pour la 0.2.5 — téléchargement, extraction, et confirmation que l'empreinte du manifeste est bien celle du flux, avec zéro octet après le marqueur de fin.

🤖 Generated with Claude Code