Suite à la discussion sur le salon et pour mettre les choses à plat, je poursuis ici la discussion autour de l’usage de equivs pour la gestion des dépendances des applications.
La problématique est la suivante:
Les packages d’applications nécessitent souvent l’installation de paquets supplémentaires en dépendances indirecte. Or ces paquets sont installés manuellement lorsque l’application n’est pas installée par apt-get.
Par exemple, lutim nécessite carton et perlmagick. Mais ces dépendances sont installées manuellement.
Il est bien évidemment possible de supprimer ces paquets à la suppression de l’app, mais aucun mécanisme ne permet de savoir si une autre application utilise également ces paquets.
Leur suppression pourrait donc casser d’autres applications.
Jerome, semble-t-il, a créé un helpers à base de equivs pour pallier ce problème de dépendance.
Le principe est simple, créer un faux paquet debian ayant comme dépendance les paquets nécessaires pour l’app. Ce faisant, les dépendances sont installées par l’installation du faux paquet, on n’installe pas les dépendances manuellement. On peut donc supprimer le faux paquet dans le script remove, les paquets installés manuellement deviennent donc inutiles et seront supprimés par un autoremove.
L’intérêt ici, c’est que si une autre application avait des paquets en commun, ils restent en dépendance du faux paquet de cette application. Ils ne seront donc pas supprimés par l’autoremove.
Ça semble donc une solution idéale. Dommage de la découvrir que maintenant.
Par contre, les commentaires de code n’étant pas de mise… le helper n’est pas forcément très lisible, je propose donc une relecture de celui-ci
Le helper au complet est ici
Il prend en argument un fichier .control, un exemple avec owncloud qui donne le numéro de version, le nom du package et ses fameuses dépendances.
Le helper en détail:
ynh_package_is_installed 'equivs' \
|| ynh_package_install equivs
equivs n’est pas installé par défaut, il faut installer le paquet avant tout.
pkgname=$(grep '^Package: ' $controlfile | cut -d' ' -f 2)
pkgversion=$(grep '^Version: ' $controlfile | cut -d' ' -f 2)
[[ -z "$pkgname" || -z "$pkgversion" ]] \
&& echo "Invalid control file" && exit 1
Récupère le nom du paquet et son numéro de version, définit dans le fichier .control
ynh_package_update
apt-get update simplement.
TMPDIR=$(ynh_mkdir_tmp)
Le helper à remplacer par un simple mktemp -d, qui créer donc simplement un dossier de travail temporaire.
cp "$controlfile" "${TMPDIR}/control" \
&& cd "$TMPDIR" \
Sans commentaire, c’est simple.
equivs-build ./control 1>/dev/null \
Création du paquet deb à partir du fichier .control
Le fichier deb sera toutefois vide, c’est juste un faux paquet pour les dépendances.
sudo dpkg --force-depends \
-i "./${pkgname}_${pkgversion}_all.deb" 2>&1 \
Installation du paquet deb créé précédemment, et donc en particulier de ses dépendances.
Le –force-depends à un effet que je ne comprend pas… Mais j’ai pas fait d’essais.
ynh_package_install -f
apt-get avec les options -o Dpkg::Options::=--force-confdef et -o Dpkg::Options::=--force-confold install
Je ne sais pas ce que ça fait, pas la force de fouiller à cette heure tardive.
Je ne sais pas pourquoi il y a cette commande après le dpkg -i.
rm -rf $TMPDIR
Nettoyage à la fin, qui n’est pas forcément nécessaire je pense avec un dossier temporaire. (Quoique, sur un serveur qui redémarre rarement… Je ne sais pas comment sont géré les temporaires dans ce cas.)
ynh_package_is_installed "$pkgname"
Le helper termine en vérifiant que le faux paquet a été correctement installé.
Je pense que ce helper peux être remanié et éclairci. Et le fichier .control simplifié au maximum et renseigné automatiquement avec sed pour lui donner un nom de package adapté à l’id de l’app en cas d’app multi-instance.
Cette solution avec equivs me semble la solution la plus intéressante à notre disposition pour gérer les dépendances des packages d’applications Yunohost.