Comme tu le dis il y a un processus dans l’iso ( et peut être aussi les bons packages a mettre de base ) c’est plus pour décortiquer ce qui est dedans
PS : je sais bien qu’une ISO c’est pas une image ou un container ;)) c’est juste le processus d’installation qui est dedans qui pourrait ( peut être ) être analyser pour le transposer
Quand jeedom est redémarré il ne relance pas de dépendances.
Il vérifie si les Démon sont OK ou NOK
Quand il m’arrive de redémarrer mon conteneur, jeedom exécute de lui-même cette fonction
Pour les ISO ; ce sont des images mise à disposition sur le docker Hub qui sont toutes « presque » à l’emploi. Le core de jeedom y est installé.
Les images master et latest sont restées sur le Hub pendant deux ans avant de disparaitre il y a quelques mois.
C’est pourquoi j’ai mon tuto en « obsoléte » et j’en créé un autre sur la base de Debian Buster et avec réseau macvlan
Et effectivement, une image latest a refait surface qu’il va falloir tester.
Mais faut pas rêver ! on ne trouvera pas la « philosophie » docker avec un découpage de service dedans
D’ailleurs en avril Loïc écrivait :
By the way I begin to develop a package manager inside jeedom core the purpose is to simplify install.sh, install.sh just install need package to start and pass the work to packages.php which install missing package.
Donc dans le fichier packages.php c’est ce qui permet ou permettrait de relancer les dépendances par exemple.