YunoHost/doc
1
0
Fork 0
mirror of https://github.com/YunoHost/doc.git synced 2024-09-03 20:06:26 +02:00
Code Issues Projects Releases Packages Wiki Activity

Fix typos

Browse source
This commit is contained in:
ericgaspar 2020-09-15 14:38:11 +02:00
parent e927fdcfe3
commit 1748b597b4
No known key found for this signature in database
GPG key ID: 574F281483054D44
2 changed files with 36 additions and 36 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
packaging_apps_guidelines.md
View file

@ -1,4 +1,4 @@
# Packing Applications : Good Practise Guidelines
# Packing Applications: Good Practise Guidelines
<div class="alert alert-danger">
<b>
@ -69,8 +69,8 @@ Each YEP is associated with:
| YEP 3.6 | Update versions containing CVE | draft | manual | OFFICIAL (6) |
| | | | | |
| ** YEP 4 ** | ** Integrate an app ** | ** Status ** | ** Test ** | ** Level ** |
| 4.1 | Link to ldap | validated | manual | OFFICIAL (4) |
| YEP 4.2 | Link authentication to sso | validated | manual | OFFICIAL (4) |
| 4.1 | Link to LDAP | validated | manual | OFFICIAL (4) |
| YEP 4.2 | Link authentication to SSO | validated | manual | OFFICIAL (4) |
| YEP 4.2.1 | Sign Out | validated | manual | OFFICIAL (9) |
| YEP 4.3 | Provide YunoHost Backup Script Functional | validated | Home | OFFICIAL (6) |
| YEP 4.4 | Provide a YunoHost Restore Functional script | validated | Home | OFFICIAL (6) |
@ -99,7 +99,7 @@ In other words, it must respect the following rules:
For application names containing spaces, virtually all current packages simply remove them without replacing them with dashes or underscores.
By convention, the YunoHost application repositories are always named their ID followed by the string "\ _ynh". Thus one can distinguish the upstream repository of the application, the deposit of the yunohost package. This notation also makes it possible to find applications not listed by the search engines of platforms offering version managers (GitHub for example).
By convention, the YunoHost application repositories are always named their ID followed by the string "\_ynh". Thus one can distinguish the upstream repository of the application, the deposit of the YunoHost package. This notation also makes it possible to find applications not listed by the search engines of platforms offering version managers (GitHub for example).
Example: ID: Example Filing Name: example_ynh
@ -119,13 +119,13 @@ For the `apps.json` list maintained by the project team, registration is on [the
##### Indicate the license associated with the package | draft | AUTO | WORKING |
The license of the packet must be specified in a `LICENSE` file at the root of the packet. Be careful not to confuse with the license of the application that will be installed whose acronym is to be entered in the `license` field of the manifest.
The application list apps.json only accept packages with a free license, as well as the license for the contained application. Some free applications require non-free dependencies (example: mp3, drivers, etc.). In this case, you should add `&dep-non-free` to the acronym and if possible give details in the README.md of the package, in this case the integration will be accepted on a case-by-case basis.
The application list apps.json only accept packages with a free license, as well as the license for the contained application. Some free applications require non-free dependencies (example: MP3, drivers, etc.). In this case, you should add `&dep-non-free` to the acronym and if possible give details in the README.md of the package, in this case the integration will be accepted on a case-by-case basis.
**NB:** Apps not included in apps.json lists may still be installed: either manually with the URL to the app, or in a more practical way using non-official lists (which can be created and maintained by the community).
In the future, YunoHost will probably display details about the license of the application. To achieve this, the acronym must be the one from this [list of licenses listed in the SPDX](https://spdx.org/licenses/) (if there are 2 acronyms, the one containing the version number). For consistency, the case must be respected.
If the license is not present in the list, in this case it is necessary to indicate `free` or `non-free` depending on whether it is free or not and give the user the opportunity to inquire in the README .md (link, explanations, ...).
If the license is not present in the list, in this case it is necessary to indicate `free` or `non-free` depending on whether it is free or not and give the user the opportunity to inquire in the README.md (link, explanations...).
Example: for a GNU Lesser General Public License (LGPL), version 3 the acronym is `LGPL-3.0` if non-free dependencies are used in this case it will be necessary to put LGPL-3.0 & dep-non-free `in the manifesto.
@ -160,7 +160,7 @@ To follow the evolution of YunoHost more generally:
#### YEP 1.7
##### Add the app to the [YunoHost-Apps Organization](https://github.com/YunoHost-Apps) | validated | manual | OFFICIAL |
Adding an app to the [YunoHost-Apps organization](https://github.com/YunoHost-Apps) lets you share apps with other contributors who might be tempted to package the targeted application .
Adding an app to the [YunoHost-Apps organization](https://github.com/YunoHost-Apps) lets you share apps with other contributors who might be tempted to package the targeted application.
It is also a way to quickly deploy a security patch if necessary in the event that the maintainer is unavailable.
@ -203,7 +203,7 @@ There is also README.md, which must and can contain:
* instructions to use it (for example to connect your smartphone or computer)
* the location to report a malfunction / request
* the roadmap / TODO
* possibly prerequisites in terms of ram memories, processor etc. (some equipment has less than 512MB of ram)
* possibly prerequisites in terms of RAM memories, processor etc. (some equipment has less than 512 MB of RAM)
#### YEP 1.10
##### Keep a clean version history | draft | manual | OFFICIAL |
@ -225,11 +225,11 @@ The manifest allows to describe an app so that YunoHost can apply the good treat
#### YEP 2.2
##### Using bash for main scripts | validated | Home | WORKING |
Action scripts (install, upgrade, remove, backup and restore) must be in the bash so that the cli / api yunohost can call them correctly.
Action scripts (install, upgrade, remove, backup and restore) must be in the bash so that the CLI/API YunoHost can call them correctly.
That being said, there is nothing to prevent other scripts or function libraries from using these scripts. These are not obliged to be in bash.
However, careful attention must be paid to the correct display of logs of information, warning, or errors. So that a user of the cli / api yunohost can understand the operation of the script just executed and if necessary repair its YunoHost instance.
However, careful attention must be paid to the correct display of logs of information, warning, or errors. So that a user of the CLI/API YunoHost can understand the operation of the script just executed and if necessary repair its YunoHost instance.
#### YEP 2.3
##### Save the answers during the installation | validated | manual | WORKING |
@ -238,12 +238,12 @@ During installation, it is necessary to save each answer to the questions in the
#### YEP 2.4
##### Detecting and Managing Errors | draft | manual | WORKING |
The install, upgrade, backup, and restore scripts must detect errors to avoid further scripting in case of blocking error or empty variable usage.
The use of trap and set -eu is recommended to detect and treat errors ([Discussion in progress](https://forum.yunohost.org/t/gestion-des-erreurs-set-e-and-or-trap/2249/5))
The use of trap and `set -eu` is recommended to detect and treat errors ([Discussion in progress](https://forum.yunohost.org/t/gestion-des-erreurs-set-e-and-or-trap/2249/5))
It is also necessary to check the contents of the variables before removing the remove script. For example, an `rm -Rf /var/www/$app` with `$app` empty would have a disastrous result.
At the beginning of the scripts, before any modifications, it is necessary to check the existence of the users mentioned at the installation, as well as the availability of the requested path, the availability of the final file of the application and the size of the passwords if necessary .
At the beginning of the scripts, before any modifications, it is necessary to check the existence of the users mentioned at the installation, as well as the availability of the requested path, the availability of the final file of the application and the size of the passwords if necessary.
Do not forget that in case of installation error the removal script will be launched automatically by the yunohost cli.
Do not forget that in case of installation error the removal script will be launched automatically by the YunoHost CLI.
#### YEP 2.5
##### Copy files correctly | draft | manual | WORKING |
@ -251,7 +251,7 @@ At the beginning of the scripts, before any modifications, it is necessary to ch
##### Cancel action if input values ​​are incorrect | validated | manual | WORKING |
Each script should verify that the input values ​​are correct.
Here are some examples :
Here are some examples:
* Check that the domain name exists
* Check that the user exists
* Check that the chosen path is available
@ -304,7 +304,7 @@ The goal is to find a more reliable method than sed to modify the configuration
##### Check availability of dependencies on ARM, x86, and x64 | validated | manual | OFFICIAL |
YunoHost installs on ARM, x86 and x64. A package should therefore be tested on these three processor architectures.
Some packages are not available on ARM, in this case it is advisable to study other solutions or to indicate in the README.md that the application does not work on ARM and to block the installation by detection of type d 'architecture.
Some packages are not available on ARM, in this case it is advisable to study other solutions or to indicate in the README.md that the application does not work on ARM and to block the installation by detection of type d'architecture.
#### YEP 2.17
##### Take the original version into account when updating | validated | manual | OFFICIAL |
@ -341,7 +341,7 @@ A web app should be able to install on a path `/path`.
#### YEP 2.18.5
##### Manage the YunoHost tile to easily navigate between applications | validated | manual | OFFICIAL |
Except in rare cases it is advisable to integrate the tile YunoHost which allows to return to the menu of the SSO. This integration is done in the nginx configuration.
Except in rare cases it is advisable to integrate the tile YunoHost which allows to return to the menu of the SSO. This integration is done in the NGINX configuration.
Some users have replaced this square with a script adding a menu at the top of each webapp.
@ -356,7 +356,7 @@ It should also be checked whether the port should be open on the router, beyond
#### YEP 3.3
##### Facilitating Source Integrity Control | draft | manual | OFFICIAL |
The upstream application should not be integrated into tarball in the source folder of the package, as this adds to the package and the git repository and does not allow verification of the integrity of the source.
The upstream application should not be integrated into tarball in the source folder of the package, as this adds to the package and the Git repository and does not allow verification of the integrity of the source.
The source must be downloaded from the official website, then its integrity must be checked before installing it.
#### YEP 3.4

38
packaging_apps_guidelines_fr.md
View file

@ -70,8 +70,8 @@ Chaque YEP est associée à :
| YEP 3.7 | Modifier correctement les dépots sources | draft | manuel | NOTWORKING (0) |
| | | | | |
| **YEP 4** | **Intégrer une app** | **Statut** | **Test** | **Niveau** |
| 4.1 | Lier au ldap | validé | manuel | OFFICIAL (4) |
| YEP 4.2 | Lier l'authentification au sso | validé | manuel | OFFICIAL (4) |
| 4.1 | Lier au LDAP | validé | manuel | OFFICIAL (4) |
| YEP 4.2 | Lier l'authentification au SSO | validé | manuel | OFFICIAL (4) |
| YEP 4.2.1 | Déconnexion | validé | manuel | OFFICIAL (9) |
| YEP 4.3 | Fournir un script de sauvegarde YunoHost fonctionnel | validé | auto | OFFICIAL (6) |
| YEP 4.4 | Fournir un script de restauration YunoHost fonctionnel | validé | auto | OFFICIAL (6) |
@ -100,7 +100,7 @@ De plus l'identifiant doit respecter l'expression régulière suivante `^[a-z0-9
Pour les noms d'applications contenant des espaces la quasi-totalité des paquets actuels les retirent simplement sans les remplacer par des tirets ou underscores.
Par convention, les dépôts d'applications YunoHost sont toujours nommés de leur ID suivis de la chaîne de caractère "\_ynh". Ainsi on peut distinguer le dépôt upstream de l'application, du dépôt du paquet yunohost. Cette notation permet également de trouver des applications non répertoriées à travers les moteurs de recherche des plateformes proposant des gestionnaires de version (GitHub par exemple).
Par convention, les dépôts d'applications YunoHost sont toujours nommés de leur ID suivis de la chaîne de caractère "\_ynh". Ainsi on peut distinguer le dépôt upstream de l'application, du dépôt du paquet YunoHost. Cette notation permet également de trouver des applications non répertoriées à travers les moteurs de recherche des plateformes proposant des gestionnaires de version (GitHub par exemple).
Exemple : ID : exemple Nom de dépôt : exemple_ynh
@ -120,25 +120,25 @@ Pour la liste `apps.json` maintenue par l'équipe du projet YunoHost, l'inscript
##### Indiquer la licence associée au paquet | brouillon | AUTO | WORKING |
La licence du paquet est à indiquer dans un fichier `LICENSE` à la racine du paquet. Attention à ne pas confondre avec la licence de l'application qui va être installée dont l'acronyme est à renseigner dans le champ `license` du manifeste.
La liste d'application apps.json n'accepte que les paquets dont la licence est libre, de même pour la licence de l'application contenue. Certaines applications libres nécessitent des dépendances non-libres (exemple: mp3, drivers, etc.). Dans ce cas, il faut ajouter `&dep-non-free` à l'acronyme et si possible donner des précisions dans le README.md du paquet, l'intégration sera dans ce cas acceptée au cas par cas.
La liste d'application apps.json n'accepte que les paquets dont la licence est libre, de même pour la licence de l'application contenue. Certaines applications libres nécessitent des dépendances non-libres (exemple: MP3, drivers, etc.). Dans ce cas, il faut ajouter `&dep-non-free` à l'acronyme et si possible donner des précisions dans le README.md du paquet, l'intégration sera dans ce cas acceptée au cas par cas.
**NB :** Les applications non-présentes dans la liste maintenue par le projet peuvent tout de même être installées : soit manuellement via le lien de l'application, soit de manière plus intégrée via des listes non-officielles (qui peuvent être créées et maintenues par la communauté).
Dans le futur, YunoHost affichera sans doute des détails sur la licence de l'application. Pour y parvenir, l'acronyme doit être celui issu de cette [liste de licences répertoriées du SPDX](https://spdx.org/licenses/) (si il y a 2 acronymes, il faut prendre celui contenant le numéro de version). Pour plus de cohérence, la casse doit être respectée.
Si la licence n'est pas présente dans la liste, dans ce cas il faut indiquer `free` ou `non-free` selon qu'elle est libre ou non et donner l'occasion à l'utilisateur de se renseigner dans le README.md (lien, explications, ...).
Si la licence n'est pas présente dans la liste, dans ce cas il faut indiquer `free` ou `non-free` selon qu'elle est libre ou non et donner l'occasion à l'utilisateur de se renseigner dans le README.md (lien, explications...).
Exemple: pour une licence `GNU Lesser General Public License (LGPL), version 3` l'acronyme est `LGPL-3.0` si toutefois des dépendances non libres sont utilisées dans ce cas il faudra mettre `LGPL-3.0&dep-non-free` dans le manifeste.
Exemple : pour une licence `GNU Lesser General Public License (LGPL), version 3` l'acronyme est `LGPL-3.0` si toutefois des dépendances non libres sont utilisées dans ce cas il faudra mettre `LGPL-3.0&dep-non-free` dans le manifeste.
Si une application a des modules liés avec une autre licence (Exemple: Odoo 9 LGPL-3.0 + un module sous licence AGPL-3.0 ), dans ce cas on indiquera les deux licences séparées par un `&`.
Si une application a des modules liés avec une autre licence (Exemple : Odoo 9 LGPL-3.0 + un module sous licence AGPL-3.0 ), dans ce cas on indiquera les deux licences séparées par un `&`.
Si deux applications distinctes sont dans le même paquet d'installation et ont des licences distinctes, dans ce cas on peut utiliser le `,` pour séparer les licences.
Dans les deux cas, le mainteneur est encouragé à réfléchir à la possibilité de créer deux paquets distincts. Le manifeste de chaque application permet de poser des questions de type `app` de façon à faire référence à une autre application déjà installée.
Rappel: une question de type `app` prend pour réponse l'identifiant d'une des apps déjà installée.
Rappel : une question de type `app` prend pour réponse l'identifiant d'une des apps déjà installée.
Quelques liens intéressants pour aider au choix de licence:
Quelques liens intéressants pour aider au choix de licence :
* [Des fiches explicatives sur les licences libres](https://www.inria.fr/content/download/5896/48452/version/2/file/INRIA_recueil_fiches_licences_libres_vf.pdf)
* [La documentation sur les licences du projet GNU](https://www.gnu.org/licenses/licenses.fr.html)
* [Un guide du projet GNU pour aider au choix d'une licence](https://www.gnu.org/licenses/license-recommendations.fr.html)
@ -204,7 +204,7 @@ Il y a également le README.md, ce dernier doit et peut contenir :
* des instructions pour l'utiliser (par exemple pour relier son smartphone ou son ordinateur)
* l'endroit pour signaler un dysfonctionnement / une demande
* la roadmap/TODO
* éventuellement les pré-requis en termes de mémoires ram, processeur etc. (certains équipements ont moins de 512Mo de ram)
* éventuellement les pré-requis en termes de mémoires RAM, processeur etc. (certains équipements ont moins de 512 Mo de RAM)
#### YEP 1.10
##### Garder un historique de version propre | brouillon | manuel | OFFICIAL |
@ -226,11 +226,11 @@ Le manifeste permet de décrire une app afin que YunoHost puisse lui appliquer l
#### YEP 2.2
##### Utiliser bash pour les scripts principaux | validé | auto | WORKING |
Les scripts d'action (install, upgrade, remove, backup et restore) doivent être en bash afin que la cli/api yunohost puisse correctement les appeler.
Les scripts d'action (install, upgrade, remove, backup et restore) doivent être en bash afin que la CLI/API YunoHost puisse correctement les appeler.
Ceci étant, rien n'empêche à l'intérieur de ces scripts de faire appel à d'autres scripts ou bibliothèques de fonction. Ceux-ci ne sont pas obligés d'être en bash.
Cependant, il faudra porter une attention particulière à l'affichage correct des logs d'information, de warning, ou d'erreurs. Afin qu'un utilisateur de la cli/api yunohost puisse comprendre le fonctionnement du script venant d'être exécuté et au besoin réparer son instance YunoHost.
Cependant, il faudra porter une attention particulière à l'affichage correct des logs d'information, de warning, ou d'erreurs. Afin qu'un utilisateur de la CLI/API YunoHost puisse comprendre le fonctionnement du script venant d'être exécuté et au besoin réparer son instance YunoHost.
#### YEP 2.3
##### Sauvegarder les réponses lors de l'installation | validé | manuel | WORKING |
@ -239,12 +239,12 @@ Lors de l'installation, il est nécessaire de sauvegarder chaque réponse aux qu
#### YEP 2.4
##### Détecter et gérer les erreurs | brouillon | manuel | WORKING |
Les scripts install, upgrade, backup et restore doivent détecter les erreurs pour éviter la poursuite des scripts en cas d'erreur bloquante ou d'usage de variable vide.
L'usage de trap et de set -eu est recommandé pour détecter et traiter les erreurs ([Discussion en cours à ce sujet](https://forum.yunohost.org/t/gestion-des-erreurs-set-e-et-ou-trap/2249/5))
L'usage de trap et de `set -eu` est recommandé pour détecter et traiter les erreurs ([Discussion en cours à ce sujet](https://forum.yunohost.org/t/gestion-des-erreurs-set-e-et-ou-trap/2249/5))
Il est nécessaire également de vérifier le contenu des variables avant les suppressions du script remove. Par exemple un `rm -Rf /var/www/$app` avec `$app` vide aurait un résultat désastreux.
Au début des scripts, avant toutes modifications, il faut vérifier l'existence des utilisateurs mentionné à l'installation, ainsi que la disponibilité du path demandé, la disponibilité du dossier final de l'application et la taille des mots de passe le cas échéant.
N'oubliez pas qu'en cas d'erreur d'installation le script de suppression sera lancé automatiquement par la cli yunohost.
N'oubliez pas qu'en cas d'erreur d'installation le script de suppression sera lancé automatiquement par la CLI YunoHost.
#### YEP 2.5
##### Copier correctement des fichiers | brouillon | manuel | WORKING |
@ -262,7 +262,7 @@ Dans le cas où l'une des valeurs est incorrecte, il est alors nécessaire d'ann
#### YEP 2.7
##### Donner des permissions suffisantes aux instructions bash | validé | auto | WORKING |
Certaines instructions nécessitent les droits sudo. Il faut dans ce cas ne pas oublier de préfixer ces instructions par `sudo `.
Certaines instructions nécessitent les droits sudo. Il faut dans ce cas ne pas oublier de préfixer ces instructions par `sudo`.
Dans d'autres cas il est nécessaire de donner des droits à l'aide de chmod et de chown.
@ -343,7 +343,7 @@ Une web app devraient pouvoir s'installer sur un chemin `/path`.
#### YEP 2.18.5
##### Gérer la tuile YunoHost pour naviguer facilement entre les applications | validé | manuel | OFFICIAL |
Sauf dans de rare cas il est conseillé d'intégrer la tuile YunoHost qui permet de retourner sur le menu du SSO. Cette intégration se fait dans la configuration nginx.
Sauf dans de rare cas il est conseillé d'intégrer la tuile YunoHost qui permet de retourner sur le menu du SSO. Cette intégration se fait dans la configuration NGINX.
Certains utilisateurs ont remplacé ce carré par un script ajoutant un menu en haut de chaque webapp.
@ -358,13 +358,13 @@ Il convient également de vérifier si le port doit être ouvert sur le routeur,
#### YEP 3.3
##### Faciliter le contrôle de l'intégrité des sources | brouillon | manuel | OFFICIAL |
L'application upstream ne doit pas être intégrée en tarball dans le dossier source du package, car cela alourdit le package et le dépôt git et ne permet pas la vérification de l'intégrité de la source.
L'application upstream ne doit pas être intégrée en tarball dans le dossier source du package, car cela alourdit le package et le dépôt Git et ne permet pas la vérification de l'intégrité de la source.
La source doit donc être téléchargée depuis le site officiel, puis son intégritée doit être vérifiée avant de l'installer.
#### YEP 3.4
##### Isoler l'app | brouillon | manuel | OFFICIAL |
Afin d'éviter des effets de bords en cas de compromission éventuelle de l'application, celle-ci doit être isolée pour ne pas risquer d'impacter les autres applications.
Pour cela, il convient d'isoler l'application dans son dossier d'exécution en restreignant son environnement par un chroot, soit par un mécanisme interne à l'application lorsque c'est possible (par exemple pour un serveur ftp), soit par l'usage de phpfpm.
Pour cela, il convient d'isoler l'application dans son dossier d'exécution en restreignant son environnement par un chroot, soit par un mécanisme interne à l'application lorsque c'est possible (par exemple pour un serveur FTP), soit par l'usage de PHP-FPM.
De même, pour restreindre la portée de l'utilisateur exécutant l'application, il est préférable d'utiliser un utilisateur dédiée à l'application. Dont les droits sont restreint à l'usage de l'application uniquement.
Toutefois, cela ne doit pas exempter d'une restriction maximale des droits sur les fichiers de l'application. Autant que possible, les fichiers doivent appartenir à root, et l'utilisateur dédié ne doit avoir de droits d'écriture que sur les fichiers le réclamant expressément.
@ -400,7 +400,7 @@ Dans tous les cas, une app ne devrait pas modifier les dépôts sources pour les
Cette meta YEP traite de l'intégration d'une app avec l'environnement YunoHost. Une bonne intégration est en général un gage de qualité et de confort pour les utilisateurs.
#### YEP 4.2
##### Lier l'authentification au sso | validé | manuel | OFFICIAL |
##### Lier l'authentification au SSO | validé | manuel | OFFICIAL |
Le Single Sign On permet d'éviter d'avoir à créer les mêmes utilisateurs pour chaque app. Ainsi, un utilisateur YunoHost pourra se connecter via le Single Sign On à l'ensemble des apps.
Pour se faire, il convient de lier son app au LDAP et/ou d'utiliser des hooks pour dupliquer les identifiants du compte dans la base de données de l'app.