Directives de spécifications de conformité et de packaging pour MeeGo
Vue d'ensemble rapide
Voici en bref comment procéder.
- Introduction
- Conformité 3.1.1 — Noms
- Conformité 3.1.2 — Dépendances
- Conformité 3.1.3 — Intégration avec RPM
- Conformité 3.1.4 — Disposition dans le système de fichiers
- Conformité 3.1.5 — Intégration du fichier .desktop
- Conformité 3.2.1 — Conformité des exécutables de l'application
- Conformité 3.2.2 — Utilisation des jeux d'instructions dépendant de l'implémentation
- Félicitations
Introduction
Avant de commencer à lire cet article, prenez connaissance de la section Quality/Compliance de MeeGo. Cette section vous initiera de manière détaillée au standard de conformité des applications et des appareils. Elle vous expliquera également comment configurer les outils de conformité de manière à pouvoir tester votre propre application avant de la soumettre dans la boutique AppUp.
Dans cet article, je m'attacherai à décrire ce que vous devez faire pour créer un package RPM d'installation compatible MeeGo et prêt à être soumis sur la boutique AppUp.
Voici les principaux points de conformité. Pour plus d'informations, ne manquez pas de lire le document de conformité.
Conformité 3.1.1 — Noms
Le nom du package d'application doit commencer par l'un des noms de domaine qualifié complet du propriétaire, en minuscules, dans l'ordre inverse, et il doit se terminer par le nom de l'application (exemple : com.nomsociete.nomapplication).
Cette condition requise est là pour aider les applications à éviter les conflits de noms et à garantir que toute personne soumettant une application sur la boutique AppUp dispose d'un nom reconnaissable et commercialisable pour le fichier d'installation.
Conformité 3.1.2 — Dépendances
Les packages d'application DOIVENT exiger (« require » en terminologie RPM) tous les composants système nécessaires à leur exécution. Ils PEUVENT omettre les dépendances optionnelles pour peu que cette omission n'affecte pas la capacité de l'application à fonctionner de manière conviviale. En d'autres termes, l'omission d'une dépendance ne doit pas permettre à l'application de s'installer correctement, en s'avérant par la suite incapable de fonctionner correctement. Les packages d'applications NE PEUVENT PAS dépendre de fonctionnalités extérieures à cette spécification car cela affecterait la capacité de l'application à s'installer.
Les dépendances envers les composants système sont autorisés en termes de noms de packages ou en termes de fonctionnalités.
Le format de package RPM autorise le développeur/packageur à spécifier d'autres packages RPM comme dépendances d'installation. En d'autres terme, cette exigence requiert que, si vous avez besoin que d'autres packages soient installés pour que votre application puisse fonctionner, vous devez les exiger (« require »). La seconde partie de ma dernière phrase est extrêmement importante. Si vous le voulez bien, je vais la formuler à nouveau.
Les packages d'applications NE PEUVENT PAS dépendre de fonctionnalités extérieures à cette spécification (la spécification de conformité) car cela affecterait la capacité de l'application à s'installer.
Cela veut dire que, si vous avez des dépendances d'installation, vous devez savoir si elles font partie des packages spécifiés par la spécification de conformité MeeGo. Si elles font partie de la spécification, elles seront présentes sur n'importe quel appareil compatible MeeGo et vous pouvez vous contenter de les « require » dans le RPM. En revanche, si le package tierce partie dont vous avez besoin n'est pas spécifié dans la spécification de conformité, vous devez regrouper la bibliothèque tierce partie. Cela signifie également que l'utilisation des référentiels tierce partie par les applications MeeGo n'est pas autorisée. Au lieu d'utiliser un référentiel tierce partie, vous devez télécharger les bibliothèques et les regrouper dans votre RPM.
Conformité 3.1.3 — Intégration à RPM
Les packages d'application doivent être créés de manière à ce que le système de gestion des packages sache quels sont les fichiers à installer. Les requêtes effectuées à l'aide des outils standard de gestion des packages sur les packages installés doivent fonctionner comme attendu.
Les packages qui installent la totalité des fichiers dans un script de post-installation ne sont pas conformes. L'application doit se désinstaller proprement, en laissant le système dans l'état où il se trouvait avant l'installation (exception faite des éléments ajoutés par l'utilisateur : fichiers ou configurations).
En d'autres termes, l'installation et la désinstallation doivent s'effectuer à la manière RPM habituelle et la désinstallation doit supprimer tout ce que l'installation a apporté avec elle.
Voici quelques exemples de la manière dont RPM doit pouvoir utiliser vos fichiers d'installation.
Exemples :
- Trouver le package auquel appartient un fichier : $ rpm –q –-file nomfichier
- Afficher la liste de tous les fichiers installés par un package : $ rpm –ql nompackage
Conformité 3.1.4 — Disposition dans le système de fichiers
L'application doit être installée dans le répertoire /opt/nompackage/ et, si nécessaire, dans les répertoires /etc/opt/ nompackage/ et dans /var/opt/nompackage/ Les fichiers de configuration de niveau ensemble du système doivent être placés dans le répertoire /etc/opt/nompackage Les données variables d'un package (fichiers de verrouillage, fichiers mis en cache, etc.) doivent être placées dans le répertoire /var/opt/nompackage plutôt que dans /var, sauf si un emplacement spécifique est nécessaire au fonctionnement correct de l'application ou du système. Les fichiers spécifiques à l'utilisateur doivent être stockés dans le répertoire ~/.config/nompackage. En définissant des portions du système de fichiers dont on est sûr qu'elles appartiennent exclusivement à l'application, ces règles ont pour but d'éviter les conflits de noms de fichiers entre les packages d'application et avec les fichiers du système.
Cette condition requiert tout bonnement que les fichiers binaires, les fichiers de configuration du système, les fichiers comme les fichiers de verrouillage et les fichiers mis en cache, ainsi que les fichiers spécifiques à l'utilisateur, aient tous leurs répertoires appropriés.
Conformité 3.1.5 — Intégration du fichier .desktop
Un fichier .desktop doit être installé dans /usr/share/applications et il doit contenir des valeurs pour au moins les champs suivants : Name, Comment, [Exec ou Link], Icon, Type et Categories. Le fichier d'image spécifié dans le champ Icon du fichier .desktop doit être au format SVG ou PNG. Pour le format 1, il doit être fourni dans les tailles suivantes : 16x16, 32x32, 64x64 et 128x128.
La première partie de cette condition requiert que vous devez créer le fichier .desktop pour votre application. Ce fichier .desktop stocke des détails sur le lancement de l'application (nom de l'application, variables d'environnement, emplacement de l'icône, etc.). La spécification Desktop Entry est maintenue par freedesktop.org.
Voici un exemple de fichier .desktop (en l'occurrence, celui de l'application d'aide de MeeGo) :
[Desktop Entry]
Version=1.0
Name=Aide MeeGo
Comment=Application d'aide MeeGo
Type=Application
Icon=moblin-logo-icon
Terminal=false
Exec=meego-help
Categories=Utility;
La seconde partie de cette condition indique les tailles requises des icônes fournies avec l'application.
Conformité 3.2.1 — Conformité des exécutables de l'application
Tous les exécutables de fichiers binaires et toutes les bibliothèques partagées compatibles MeeGo doivent être au format ELF (voir section 2.4.1). Ils ne doivent importer d'interfaces externes que des sources suivantes :
- bibliothèques partagées fournies comme faisant partie du package de l'application
- bibliothèques partagées MeeGo Core, si l'interface fait partie des interfaces publiques de cette bibliothèque
En outre, l'exécutable peut utiliser des interfaces publiques provenant de bibliothèques partagées spécifiques à un profil MeeGo, mais, dans ce cas, l'application ne sera compatible qu'avec ce profil.
Si l'exécutable est un plug-in de composant système MeeGo, il peut importer des interfaces à partir d'un exécutable du composant système et à partir des bibliothèques partagées chargées comme faisant partie de cet exécutable.
Là aussi, cette condition requiert qu'une application compatible MeeGo ne doit être liée qu'aux bibliothèques partagées MeeGo Core. La raison en est que ces bibliothèques sont déjà installées sur tout appareil compatible MeeGo.
La condition qui requiert que les exécutables soient au format ELF ne concerne que les fichiers binaires de l'application. Les langages de script comme Python, Perl, Ruby, etc. sont parfaitement acceptables.
Les profils MeeGo, parfois appelés « Verticals », sont la combinaison des packages d'installation MeeGo Core et de packages d'installation de profils particuliers. À l'heure actuelle, les différents profils sont les netbooks MeeGo , les tablettes MeeGo, les systèmes automobiles d'infoloisirs MeeGo (IVI pour In-Vehicle Infotainment) et MeeGo Handset. Si, par exemple, une application utilise des API qui sont fournies par le profil des tablettes MeeGo, cette application ne sera compatible que pour des tablettes et non pour les autres profils.
La dernière phrase de la section 3.2.1 stipule que, si une application est créée à l'aide de composants, la liaison à ces composants est autorisée par les directives de conformité MeeGo.
Conformité 3.2.2 — Utilisation des jeux d'instructions dépendant de l'implémentation
Lors de la construction de fichiers binaires, un fichier binaire d'application ou une bibliothèque partagée PEUVENT utiliser des extensions de l'architecture CPU et des fonctions spécifiques à l'implémentation. Si cette utilisation doit limiter la portabilité de l'application, celle-ci doit clairement identifier les restrictions que cela impose (les référentiels/boutiques de l'application doivent être capables d'exclure les appareils non applicables). Le mécanisme de ce filtrage n'est pas spécifié.
Si vous utilisez des jeux d'instructions spécifiques à une CPU, vous devez déclarer le côté restrictif de votre application.
Conclusion
Nous avons examiné de près les détails des directives de conformité MeeGo pour les applications en espérant les avoir clairement expliquées. Pour toute autre question concernant ces directives, vous pouvez consulter ces ressources.
- Page wiki Qualité et conformité MeeGo.
- Séminaire tenu en 2010 sur la conformité MeeGo.
- Les forums MeeGo.
La gestion de l'énergie pour les futures tablettes MeeGo propose quelques recommandations additionnelles. Reportez-vous aux liens ci-dessous pour de plus amples informations sur la gestion de l'énergie et pour modifier le fichier .desktop conformément à cette recommandation.
Questions - Réponses sur la gestion de l'énergie
Gestion de l'énergie - Fichier .desktop
