Demande #37054
Mis à jour par Benjamin Bohard il y a 7 mois
Pour gérer l’installation en mode conteneur, on utilise les mécanismes creole (balise package).
Ce mécanisme ne rend pas visible la notion de dépendance entre les paquets eole-* et *-pkg ou *-apps (pour les applications envole) pour les procédures de mise à jour.
Dans le cas du passage à l’utilisation de php-fpm, s’appuyant sur la mise à disposition d’un nouveau dépôt de paquets, on tombe sur un problème d’organisation des mises à jour :
- le paquet eole-common apporte la déclaration du nouveau dépôt ;
- le paquet envole-dependances-apps (déclaré dans un dictionnaire pour le conteneur web) dépend des paquets de ce nouveau dépôt ;
- les configurations apache des applications apportées sous forme de template dans les paquets eole-* nécessite php-fpm et les différentes versions de PHP ;
On a donc une dépendance de version entre des paquets sur l’hôte (eole-common, eole-* pour les applications web) et le paquet envole-dependances-apps dans le conteneur. Cette dépendance n’est pas déclarée dans les debian/control et n’est donc pas identifiable par la commande Maj-Auto.
Côté packaging, on peut aisément déclarer une dépendance entre <notextile>*-pkg, *-pkg, *-apps sur envole-dependances-apps mais ça n’empêche pas, en l’état, la mise à jour des eole-*</notextile> eole-* correspondants amenant à une incohérence potentielle.
Par contre, on peut assez facilement associer les couples de paquets eole-* et *-apps, *-pkg dans le code de Maj-Auto.
La proposition présentée dans le patch joint consiste donc à évaluer la dépendance entre les paquets eole-* et les paquets <notextile>*-apps, *-apps, *-pkg pour bloquer la mise à jour des paquets eole-* si les paquets correspondants *-apps, *-pkg ont eux-même leur mise à jour bloquée (attribut marked_keep). Ce blocage de la mise à jour des paquets *-apps, *-pkg est gérable avec les techniques classiques de packaging</notextile>. packaging.
Par exemple, en prenant le cas de l’application grr dans le cas du passage à php-fpm :
- la déclaration du dépôt sera faite avec eole-server >> 2.9.0-85 ;
- la mise à jour de envole-dependances-apps >> 1.0+3-11 est bloquée tant que le nouveau dépôt n’est pas configuré ;
- en mettant envole-dependances-apps (>> 1.0+3-11) en dépendances de grr-apps, on bloque la mise à jour de ce dernier dans les mêmes conditions => ce paquet prend l’attribut marked_keep True ;
- au moment de faire la liste des paquets à mettre à jour, on peut vérifier que eole-grr est "associé" à grr-apps et, ce dernier ayant marked_keep True, prendre la décision d’exclure eole-grr de la mise à jour.
Par ce biais, on peut avoir une cohérence entre la configuration apportée sur l’hôte et les paquets des conteneurs.
J’ai abordé le problème par le biais des noms de paquets (eole-*, *-apps|pkg) plutôt que par le contenu des dictionnaires pour la raison que les problèmes de cohérence affectent seulement les paquets issus du même dépôt, a priori. La classe Package utilisée pour accéder aux informations des paquets ne semble pas permettre d’accéder à l’origine du paquet, c’est pourquoi le nom est proposé comme critère d’association (la convention de nommage est bien suivie dans les projets EOLE et Envole).
On pourrait compléter avec le contrôle strict de la version de ces paquets (vérifier que ces paquets associés ont la même version).
Ce mécanisme ne rend pas visible la notion de dépendance entre les paquets eole-* et *-pkg ou *-apps (pour les applications envole) pour les procédures de mise à jour.
Dans le cas du passage à l’utilisation de php-fpm, s’appuyant sur la mise à disposition d’un nouveau dépôt de paquets, on tombe sur un problème d’organisation des mises à jour :
- le paquet eole-common apporte la déclaration du nouveau dépôt ;
- le paquet envole-dependances-apps (déclaré dans un dictionnaire pour le conteneur web) dépend des paquets de ce nouveau dépôt ;
- les configurations apache des applications apportées sous forme de template dans les paquets eole-* nécessite php-fpm et les différentes versions de PHP ;
On a donc une dépendance de version entre des paquets sur l’hôte (eole-common, eole-* pour les applications web) et le paquet envole-dependances-apps dans le conteneur. Cette dépendance n’est pas déclarée dans les debian/control et n’est donc pas identifiable par la commande Maj-Auto.
Côté packaging, on peut aisément déclarer une dépendance entre <notextile>*-pkg, *-pkg, *-apps sur envole-dependances-apps mais ça n’empêche pas, en l’état, la mise à jour des eole-*</notextile> eole-* correspondants amenant à une incohérence potentielle.
Par contre, on peut assez facilement associer les couples de paquets eole-* et *-apps, *-pkg dans le code de Maj-Auto.
La proposition présentée dans le patch joint consiste donc à évaluer la dépendance entre les paquets eole-* et les paquets <notextile>*-apps, *-apps, *-pkg pour bloquer la mise à jour des paquets eole-* si les paquets correspondants *-apps, *-pkg ont eux-même leur mise à jour bloquée (attribut marked_keep). Ce blocage de la mise à jour des paquets *-apps, *-pkg est gérable avec les techniques classiques de packaging</notextile>. packaging.
Par exemple, en prenant le cas de l’application grr dans le cas du passage à php-fpm :
- la déclaration du dépôt sera faite avec eole-server >> 2.9.0-85 ;
- la mise à jour de envole-dependances-apps >> 1.0+3-11 est bloquée tant que le nouveau dépôt n’est pas configuré ;
- en mettant envole-dependances-apps (>> 1.0+3-11) en dépendances de grr-apps, on bloque la mise à jour de ce dernier dans les mêmes conditions => ce paquet prend l’attribut marked_keep True ;
- au moment de faire la liste des paquets à mettre à jour, on peut vérifier que eole-grr est "associé" à grr-apps et, ce dernier ayant marked_keep True, prendre la décision d’exclure eole-grr de la mise à jour.
Par ce biais, on peut avoir une cohérence entre la configuration apportée sur l’hôte et les paquets des conteneurs.
J’ai abordé le problème par le biais des noms de paquets (eole-*, *-apps|pkg) plutôt que par le contenu des dictionnaires pour la raison que les problèmes de cohérence affectent seulement les paquets issus du même dépôt, a priori. La classe Package utilisée pour accéder aux informations des paquets ne semble pas permettre d’accéder à l’origine du paquet, c’est pourquoi le nom est proposé comme critère d’association (la convention de nommage est bien suivie dans les projets EOLE et Envole).
On pourrait compléter avec le contrôle strict de la version de ces paquets (vérifier que ces paquets associés ont la même version).