Demande #37054
Mis à jour par Daniel Dehennin 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-*@* eole-* et *@*-pkg@* *-pkg ou *@*-apps@* *-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@* eole-common apporte la déclaration du nouveau dépôt ;
* - le paquet *@envole-dependances-apps@* 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-*@* 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-*@* (eole-common, eole-* pour les applications web) et le paquet *@envole-dependances-apps@* envole-dependances-apps dans le conteneur. Cette dépendance n’est pas déclarée dans les *@debian/control@* 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 *@*-pkg@*, *@*-apps@* <notextile>*-pkg, *-apps sur envole-dependances-apps mais ça n’empêche pas, en l’état, la mise à jour des *@eole-*@* eole-*</notextile> correspondants amenant à une incohérence potentielle.
Par contre, on peut assez facilement associer les couples de paquets *@eole-*@* eole-* et *@*-apps@*, *@*-pkg@* *-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-*@* eole-* et les paquets *@*-apps@*, *@*-pkg@* <notextile>*-apps, *-pkg pour bloquer la mise à jour des paquets *@eole-*@* eole-* si les paquets correspondants *@*-apps@*, *@*-pkg@* *-apps, *-pkg ont eux-même leur mise à jour bloquée (attribut *@marked_keep@*). marked_keep). Ce blocage de la mise à jour des paquets *@*-apps@*, *@*-pkg@* *-apps, *-pkg est gérable avec les techniques classiques de packaging. packaging</notextile>.
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 eole-server >> 2.9.0-85@* 2.9.0-85 ;
* - la mise à jour de *@envole-dependances-apps envole-dependances-apps >> 1.0+3-11@* 1.0+3-11 est bloquée tant que le nouveau dépôt n’est pas configuré ;
* - en mettant *@envole-dependances-apps envole-dependances-apps (>> 1.0+3-11)@* 1.0+3-11) en dépendances de *@grr-apps@*, grr-apps, on bloque la mise à jour de ce dernier dans les mêmes conditions => ce paquet prend l’attribut *@marked_keep True@* marked_keep True ;
* - au moment de faire la liste des paquets à mettre à jour, on peut vérifier que *@eole-grr@* eole-grr est "associé" à *@grr-apps@* grr-apps et, ce dernier ayant *@marked_keep True@*, marked_keep True, prendre la décision d’exclure *@eole-grr@* 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@*) (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-*@* eole-* et *@*-pkg@* *-pkg ou *@*-apps@* *-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@* eole-common apporte la déclaration du nouveau dépôt ;
* - le paquet *@envole-dependances-apps@* 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-*@* 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-*@* (eole-common, eole-* pour les applications web) et le paquet *@envole-dependances-apps@* envole-dependances-apps dans le conteneur. Cette dépendance n’est pas déclarée dans les *@debian/control@* 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 *@*-pkg@*, *@*-apps@* <notextile>*-pkg, *-apps sur envole-dependances-apps mais ça n’empêche pas, en l’état, la mise à jour des *@eole-*@* eole-*</notextile> correspondants amenant à une incohérence potentielle.
Par contre, on peut assez facilement associer les couples de paquets *@eole-*@* eole-* et *@*-apps@*, *@*-pkg@* *-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-*@* eole-* et les paquets *@*-apps@*, *@*-pkg@* <notextile>*-apps, *-pkg pour bloquer la mise à jour des paquets *@eole-*@* eole-* si les paquets correspondants *@*-apps@*, *@*-pkg@* *-apps, *-pkg ont eux-même leur mise à jour bloquée (attribut *@marked_keep@*). marked_keep). Ce blocage de la mise à jour des paquets *@*-apps@*, *@*-pkg@* *-apps, *-pkg est gérable avec les techniques classiques de packaging. packaging</notextile>.
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 eole-server >> 2.9.0-85@* 2.9.0-85 ;
* - la mise à jour de *@envole-dependances-apps envole-dependances-apps >> 1.0+3-11@* 1.0+3-11 est bloquée tant que le nouveau dépôt n’est pas configuré ;
* - en mettant *@envole-dependances-apps envole-dependances-apps (>> 1.0+3-11)@* 1.0+3-11) en dépendances de *@grr-apps@*, grr-apps, on bloque la mise à jour de ce dernier dans les mêmes conditions => ce paquet prend l’attribut *@marked_keep True@* marked_keep True ;
* - au moment de faire la liste des paquets à mettre à jour, on peut vérifier que *@eole-grr@* eole-grr est "associé" à *@grr-apps@* grr-apps et, ce dernier ayant *@marked_keep True@*, marked_keep True, prendre la décision d’exclure *@eole-grr@* 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@*) (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).