Gestion des sources des apps dans les packages

Afin de poursuivre et tenter de conclure cette discussion de longue date, je relance ce sujet ici.

La question étant, comment gérer les sources des applications au sein des packages? L’idéal serait de trouver une solution unifiée, pouvant ensuite être simplifiée par un helper.

Cette discussion a déjà été débattu sur redmine. https://dev.yunohost.org/issues/201
Je propose donc de la poursuivre.

Il apparaît clairement que la solution de la source en tarball dans le dossier source est à proscrire car elle fait gonfler la taille du dépôt à chaque mise à jour.

Les contraintes sont les suivantes :

  • Limiter l’embonpoint du dépôt.
  • Faciliter le suivi du changement de version.
  • S’assurer de la provenance de la source.
  • Vérifier l’intégrité de la source.

En ce qui me concerne, à ce jour, j’utilise un helper perso.
https://github.com/maniackcrudelis/modele_ynh/blob/master/scripts/.fonctions#L72-L91

Il se base sur 3 fichiers dans le dossier source:

  • source_url, qui contient l’adresse de la source à télécharger.
  • source_md5, qui contient la somme de contrôle de la source.
  • source_dir, qui contient le nom de la source après décompression.
2 Likes

Salut. Moul a tout dit je trouve. Je suis d’accord avec son diagnostic et surtout son ordre de priorité à favoriser

  1. Upstream checksum
  2. Subtrees
  3. Submodules
  4. Copy/Paste

Par contre je ne suis pas sur que ces actions doivent être faites via un helper. L’action de base ne prend que quelques lignes et est quand même très spécifique au package. La “bundliser” en un helper revient à la complexifier plutôt qu’a la simplifier selon moi. La je passerais plus de temps à piger le helper et sa structure qu’à comprendre 3 lignes d’exemples…

Par contre dans la d’oc packaging ou l’exemple_ynh on peut mettre des exemples de chaque (comme actuellement le copy/paste

1 Like

Je ne connais pas du tout l’usage des submodule et subtree.
Et après un peu de lecture
http://www.git-attitude.fr/2014/12/31/git-submodules/
http://www.git-attitude.fr/2015/01/30/git-subtrees/

Il en ressort que j’ai pas tenu jusqu’à la fin des articles… Et j’ai tellement survolé que j’ai toujours pas compris le véritable intérêt…

A mon avis, la méthode à plébisciter reste le téléchargement des sources, car c’est simple et fiable.

L’usage d’un helpers à plusieurs intérêts à mon avis

  • Simplifier l’usage, une commande suffit.
  • Forcer la vérification de la somme de contrôle, qui est globalement pas faite aujourd’hui
  • Uniformiser la méthode.
  • Éviter des erreurs de copies par oubli du . en fin de cp

Après mon helper est un exemple, c’est juste celui que j’utilise pour le moment.

Les subtree et submodules sont des méthodes pour intégrer des dépôts git modulaire au sein d’un autre dépôt git.

1 Like

J’ai sans doute pas compris non plus les subtilités …
Il m’avait semblé que submodule = cloner un gît mais que dans une version ou commit spécifique, et subtree = cloner tout le gît ?

Oui, c’est à peu près ça :

  • submodule : fichier contentant l’adresse et le commit du submodule. Les sources ne sont pas présente dans le dépôt principal. Il faut cloner le dépôt submodule avec l’option --recursive.
  • subtree : les commits sont présents dans le dépôt principal en parallèle des commits du dépôt principal. Le subtree peut facilement être ajouté comme supprimé.

Pour moi le subtree n’a qu’un avantage pouvoir installer l’app sur un yunohost non connecté à internet (réseau local) ou si la source upstream est down.

Certains disent que ce n’est pas utile, mais dans les faits j’ai au moins vu 2 projets humanitaires faire un usage de yunohost de cette façon.

Je pense toutefois qu’il y a mieux à faire.

En fait on pourrait tester dans le script si les sources de l’app sont disponibles localement avant de lancer un téléchargement. Par exemple on pourrait vérifier la présence des sources dans /opt/src-yunoapps (ou autre). Avec une convention de nommage, de cette façon l’administrateur du yunohost pourra importer à l’avance les sources si besoin.

Ca pourrait être utile aussi pour des personnes qui souhaitaient déployer yunohost sur de nombreux vps. Il leur suffirait de lier un répertoire de sources commun (en montant un disque réseau par exemple) et ainsi éviter de télécharger plein de fois l’app. C’est sur que cette architecture n’est pas courante, mais ça ferait peut être sens pour des assos (genre chatons) qui pourraient vouloir proposer un yunohost par utilisateur ?

Avec cette méthode (à affiner), git subtree me semble obsolete.

A part ça, il faut préférer sha256sum à md5sum…

Ça me semble intéressant comme idée oui.
Toutefois ça ne résout pas la situation pour les apps qui font un apt-get durant l’install (le subtree non plus).

Ça impliquerais également de permettre clairement à un user de télécharger les sources indépendamment de l’install.

Salut,

Le téléchargement des sources te coupe complètement des sources, de l’information sur les sources.

Par contre j’avais commencé (or yunohost) sur des submodules, mais je suis passé au subtree, beaucoup plus pratique pour les mises à jour.
Je pense reprendre le packaging de LimeSurvey (ca serait la moindre des choses), mais si je le fait cela sera avec du subtree, et sans doute du subtree supplémentaire histoire d’ajouter un plugin YunohostAuth et peut être d’autres.

Pourquoi les subtree plutôt que les submodules ou les sources :

  1. Permet d’appliquer un patch spécifique au besoin et pas toutes les modifications comme un submodule
  2. Permet de gérer séparément (éventuellement sur un fork) ses propres mises à jour et de controler la cohérences lors des mises à jour
  3. Lors d’un clone brut : le clone reçoit l’ensemble du code (pas comme un submodules)

Sinon, la solution idéale me semble bien une méthode avec : téléchargement des sources + update des sources : partir sur composer ? Sauf que , je sais par expérience qu’il est plus difficile de gérer par composer les modifications et les mises à jour.

  1. Il faut rester sur composer, donc plus difficile de gérer les modifications spécifique
  2. Plus difficile de choisir le bon package

Mais sinon : cela peut réellement être la solution idéale.

1 Like