# Gestion des sources des apps dans les packages
**URL:** https://forum.yunohost.org/t/gestion-des-sources-des-apps-dans-les-packages/2248
**Category:** Apps packaging
**Tags:** french
**Created:** [December 10, 2016, 11:14pm UTC](https://forum.yunohost.org/t/gestion-des-sources-des-apps-dans-les-packages/2248 "2016-12-10T23:14:13Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@Maniack\_Crudelis](https://forum.yunohost.org/u/Maniack_Crudelis)
#### Post date: [December 10, 2016, 11:14pm UTC](https://forum.yunohost.org/t/gestion-des-sources-des-apps-dans-les-packages/2248/1 "2016-12-10T23:14:14Z")
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](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](https://github.com/maniackcrudelis/modele_ynh/blob/master/scripts/.fonctions#L72-L91)
Il se base sur 3 fichiers dans le dossier source:
- [source\_url](https://github.com/maniackcrudelis/modele_ynh/blob/master/sources/source_url), qui contient l’adresse de la source à télécharger.
- [source\_md5](https://github.com/maniackcrudelis/modele_ynh/blob/master/sources/source_md5), qui contient la somme de contrôle de la source.
- [source\_dir](https://github.com/maniackcrudelis/modele_ynh/blob/master/sources/source_dir), qui contient le nom de la source après décompression.
---
### Author:  [@scith](https://forum.yunohost.org/u/scith)
#### Post date: [December 11, 2016, 7:47am UTC](https://forum.yunohost.org/t/gestion-des-sources-des-apps-dans-les-packages/2248/2 "2016-12-11T07:47:14Z")
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
-
---
### Author:  [@Maniack\_Crudelis](https://forum.yunohost.org/u/Maniack_Crudelis)
#### Post date: [December 11, 2016, 9:06pm UTC](https://forum.yunohost.org/t/gestion-des-sources-des-apps-dans-les-packages/2248/3 "2016-12-11T21:06:00Z")
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/2014/12/31/git-submodules/)
[http://www.git-attitude.fr/2015/01/30/git-subtrees/](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.
---
### Author:  [@Moul](https://forum.yunohost.org/u/Moul)
#### Post date: [December 11, 2016, 11:40pm UTC](https://forum.yunohost.org/t/gestion-des-sources-des-apps-dans-les-packages/2248/4 "2016-12-11T23:40:13Z")
> [@Maniack\_Crudelis](#):
>
> Je ne connais pas du tout l’usage des submodule et subtree.
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.
---
### Author:  [@scith](https://forum.yunohost.org/u/scith)
#### Post date: [December 12, 2016, 6:49am UTC](https://forum.yunohost.org/t/gestion-des-sources-des-apps-dans-les-packages/2248/5 "2016-12-12T06:49:46Z")
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 ?
---
### Author:  [@Moul](https://forum.yunohost.org/u/Moul)
#### Post date: [December 12, 2016, 9:52am UTC](https://forum.yunohost.org/t/gestion-des-sources-des-apps-dans-les-packages/2248/6 "2016-12-12T09:52:24Z")
> [@scith](#):
>
> 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é.
---
### Author:  [@ljf](https://forum.yunohost.org/u/ljf)
#### Post date: [January 15, 2017, 7:47pm UTC](https://forum.yunohost.org/t/gestion-des-sources-des-apps-dans-les-packages/2248/7 "2017-01-15T19:47:39Z")
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…
---
### Author:  [@Maniack\_Crudelis](https://forum.yunohost.org/u/Maniack_Crudelis)
#### Post date: [January 15, 2017, 9:26pm UTC](https://forum.yunohost.org/t/gestion-des-sources-des-apps-dans-les-packages/2248/8 "2017-01-15T21:26:50Z")
Ç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.
---
### Author:  [@Shnoulle](https://forum.yunohost.org/u/Shnoulle)
#### Post date: [January 16, 2017, 10:24pm UTC](https://forum.yunohost.org/t/gestion-des-sources-des-apps-dans-les-packages/2248/9 "2017-01-16T22:24:48Z")
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](https://getcomposer.org/) ? 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.
---
### Author:  [@Aleks](https://forum.yunohost.org/u/Aleks)
#### Post date: [January 18, 2023, 8:12pm UTC](https://forum.yunohost.org/t/gestion-des-sources-des-apps-dans-les-packages/2248/10 "2023-01-18T20:12:46Z")