Distribution EOLE

debsums¶

Pour ce fichier particulier, il faut bien une exception pour debsums si on ne veut pas qu’il soit listé.

système de patch le moins sale possible¶

Pour le côté sale, je retiens l’idée suivante : le patch doit se faire de manière visible et doit pouvoir être annulé.
Ça suppose de garder le patch à l’état de patch plutôt que de copier le fichier modifié.
Je suis tenté d’exclure la solution du template et du dictionnaire : ce patch est potentiellement temporaire et la modification du dictionnaire implique la mise à jour des paquets de dictionnaires pour Zéphir.

proposition 1¶

Un nouveau script posttemplate dans eole-common qui tente d’appliquer les patchs déposés dans un dossier particulier

Des paquets eole-<logiciel tiers> qui déposent des patchs (formats diff u) dans le dossier particulier et un fichier eole<logiciel tiers>.conf dans /etc/eole/debsums-ignore.d

Le script tente l’application directe (pas de prise d’initiative si le fichier cible n’a pas l’aspect attendu)

Cette approche amoindrie le risque d’appliquer le patch si le fichier à été modifié par une mise à jour du logiciel tiers.
Par contre, la suppression du patch et du fichier debsums reste à la charge du développeur.

Dans une variante plus sophistiquée, on pourrait accompagner le patch de métadonnées pour restreindre son contexte d’application (par rapport à la version du paquet du programme tiers par exemple) et créer dynamiquement les exceptions debsums mais ce n’est pas sûr qu’on soit capable de suffisamment bien décrire le contexte dans lequel le patch devrait s’appliquer pour que ce soit intéressant (que ça dispense d’avoir à réagir rapidement à la mise à jour du logiciel tiers)

root@scribe:~# dpkg -L eole-bareoswebui | grep -E "debsums|patch" 
/etc/eole/backport-patches.d
/etc/eole/backport-patches.d/eole-bareoswebui.patch
/etc/eole/debsums-ignore.d
/etc/eole/debsums-ignore.d/eole-bareoswebui.conf