Lignes directrices pour la création de paquets-fr

Autres langues English ; Français ;

Accueil [en] → Accueil → Équipes → Packageurs → Consignes

---

Attention ! Cette page est une traduction non relue d’une page qui est en cours d’élaboration et doit être réadapté à la politique d’empaquetage de Mageia. Nous vous invitons à la relire et la corriger. Les passages en Italique sont à revoir dans la version originale anglaise.

Résumé : Cette page à pour objectf de présenter les consignes d’empaquetage de Mageia qui sont basées sur celles de Mandrake/Mandriva.

Maintenir un paquet

Tous les paquets de Mageia doivent être tenus par un mainteneur (maintainer) (alias titulaire (owner), (bug owner)). Chaque paquet sans mainteneur sera automatiquement reconsidéré comme à supprimer de Mageia. Un mainteneur d’un paquet est chargé de s’assurer que :

• son paquet est à jour avec les derniers paquets en amont (upstream)
• son paquet intègre toujours le système de compilation Mageia et corrigent les erreurs de compilation lorsqu’elles se produisent
• les méta-données (meta-data) du fichier SPEC du RPM est exact
• la licence du paquet est correcte
• il/elle suit les sources en amont pour répondre aussi rapidement que possible aux mises à jour de sécurité critiques
• elle/il fournit les informations sur des changements majeurs aux autres empaqueteurs (packagers) et mainteneurs (maintainers) afin de laisser suffisamment de temps pour résoudre les problèmes de compatibilité.

Actuellement les données à propos du titulaire des paquets sont suivis dans http://pkgsubmit.mageia.org/data/maintdb.txt et les paquets non maintenus sont listés dans http://pkgsubmit.mageia.org/data/unmaintained.txt. Ils seront intégrés et gérés ultérieurement et nous laissons une période de grâce pour les paquets non maintenus. Après cette période de grâce, ces paquets sans mainteneurs seront proposés pour la suppression.

Pour vous ajouter comme mainteneur d’un paquet, veuillez suivre ces étapes :

• mettez à jour à la version la plus récente de mgarepo
• Identifiez le paquet dont vous seul seriez le mainteneur unique
• Pour chaque paquet que vous souhaitez maintenir faites :

mgarepo maintdb set [NomDuPaquet] [VotreIdentifiant]

• Ceci peut être uniquement fait par les empaqueteurs, les apprentis n’ont aucun droit sur la commande maintdb
• Vous pouvez le faire uniquement lorsque le paquet n’est maintenu actuellement par aucune personne !'
• Votre requête sera immédiatement traitée et vous serez donc le mainteneur du paquet. Acte de bienveillance, vous aidez à sauver quelques paquets non maintenus. Allez et montrer leur que vous les aimez :)

L’état actuel est visible ici : http://pkgsubmit.mageia.org/data/maintdb.txt ou si vous avez un compte comme empaqueteur complet (c.-à-d. que vous n’êtes pas un apprenti) vous pouvez directement interroger la base de données des mainteneurs avec :

mgarepo maintdb get [packagename]

ou vous pouvez demander à Sophie sur un chat de Mageia :

:maint [packagename]

[TEC] Mise à jour par un développeur autre que le responsable

Mageia a beaucoup de paquets et relativement peu d’empaqueteurs. En tant que communauté, nous faisons toujours ce que nous pouvons pour faire de Mageia une meilleure distribution et si nous empiétons sur le travail de quelqu’un, nous l’avons fait de bonne foi parce que nous voulons que Mageia soit de la meilleure qualité qui puisse exister.

Ce développement mérite un ensemble de directives ou de politiques et voici une liste des travaux en cours proposés sur @dev.

• Les remontées de révisions par le développeur sont bonnes. Il n’est pas nécessaire de demander au mainteneur, à moins qu’il s’agisse d’un changement substantiel (la plupart du temps ce sont des reconstructions ou de petites corrections).
• Les remontées de révisions par le développeur doivent être abordées avec le responsable enregistré (dans maintdb), quand :
  • Le paquet est bien établi comme étant maintenu par une personne ou un groupe de personnes (Firefox, paquets KDE, noyau, etc.)
  • Le responsable est actif, c’est-à-dire qu’il a travaillé sur des paquets, des MLs ou des bogues au cours des deux derniers mois.
  • The version bump is substantial: major/minor bump or soname change, non-trivial spec changes like syncing with another distro that was not the maintainer's documented update workflow
• Pour des raisons de sécurité, les téléchargements de développeur sont acceptables si le responsable n’a pas encore commenté le rapport de bogue et si un délai raisonnable s’est écoulé. Bien sûr, faites preuve de bon sens, si c’est le noyau ou la glibc, donnez au responsable une chance de revoir vos modifications.
• Dans d’autres cas, faites preuve d’empathie et de bon jugement. Envoyer un courriel de deux lignes à un responsable pour l’informer de votre souhait de mettre à jour un paquet, ça ne coûte rien. Souvent, on vous disait même que vous pouvez aller de l’avant et vous remercier pour votre travail, qui vaut toujours la peine d’être pris.
• Lorsque vous effectuez des téléchargements sans mainteneur, soyez prudent avec vos modifications. Ne laissez pas tomber des correctifs que vous ne comprenez pas, demandez au responsable et utilisez la solution pour mieux documenter l’objectif desdits correctifs. Ne synchronisez pas avec un nouveau fichier amont ou une autre distribution sans demander (sauf si ce paquet est identifié comme synchronisé avec une distribution donnée, par exemple rust ou Firefox).

Convention des noms de paquet

• Les noms de paquet de base (utilisé pour svn et src.rpm) doit être le même nom que celui du projet du logiciel en amont, toujours en minuscule. Le nom en amon peut contenir des chiffres, des '+', '_' ou '.', mais aucun autre caractère exceptionnel. Dans des cas exceptionnellement rares des majuscules peuvent être acceptés s’il y a une raison qui le justifie (ex : les paquets perl) ou pour des raisons historiques.
• Les noms de paquet construit pour Mageia depuis leurs noms en amont doivent uniquement juxtaposer des suffixes en utilisant le délimiteur "-" (par exemple foo-devel ou foo-plugins comme dérivé du paquet foo). Tous « _ » et « + » dans les noms des paquets doivent uniquement venir du nom du paquet en amont ! Les «.» dans les noms de paquet doivent venir aussi de l’amont ou du schéma standard du versionnage.
• Le fichier SPEC doit être nommé en suivant le schéma %{nom}.spec, autrement dit le nom du paquet source et du répertoire svn doivent être utilisés comme nom pour le SPEC.

Version et Révision (release)

La version du paquet a cette allure : X.Y.Z - R mga V
avec :

• X.Y.Z le numéro de 'version' qui est devrait représenter la version du projet
• R est la balise de révision qui est toujours incrémenté après chaque changement du paquet et avant de le soumettre pour une nouvelle construction
• mga est le suffixe de la distribution
• V est la version de la distribution

Version

Le champ 'version' du fichier spec est là où vous inscrivez la version courante du logiciel à empaqueter. Il y a des cas où la version en amont ne correspond pas au standard et contient des caractères non numériques :

• Paquets en prérévision (pre-release) : les paquets sortis en version « pre-révision » avant une version « finale ». Elle inclut par exemple des balises « alpha », « beta », « rc », « cvs », « git », « svn », etc et doit être ajouté à la balise révision (release) et non pas à la balise « version ». Vous trouverez des détails en dessous.

Versions de pré-révision

Pour les paquets de développement ou de pré-révision la balise Release (révision) doit commencer par « 0. » ainsi quand le logiciel devient « final » et ne change pas de version, nous pouvons assurer une mise à jour sûre vers une version stable simplement en changeant Release à 1.

Par exemple :

monFichierSource-2.9rc2.tar.gz a un fichier de spécification (specfile) contenant les champs Version : 2.9 et Release : %mkrel 0.rc2.1

Pour chaque reconstruction du même paquet « pré-révisé » (pre-released), incrémentez simplement la balise Release; comme ici 0.rc2.1 deviendrait 0.rc2.2 etc.

Il est recommandé d’utiliser la macro "%mkrel -c rc2 1 » pour générer 0.rc2.1.

Pour les amonts de svn ou git, il est préférable d’inclure la date de la prise en compte, avec ou sans le numéro de révision ou du git hash (qui devrait être au moins en commantaire dans le fichier spec). Les exemples suivants sont acceptables :

%mkrel -c svn20130213 1 %mkrel -c 20130213svn85423 1 %mkrel -c git20130213 1 %mkrel -c 20130213gitae25f2 1

rtmpdump peut aider à gérer ces dates de prise en compre, avec les variables %snap et %mkrel : http://svnweb.mageia.org/packages/cauldron/rtmpdump/current/SPECS/rtmpdump.spec?view=markup

Révisions (release)

Le numéro de révision (release) doit commencer par 1, et doit revenir à 1 à chaque nouvelle version, et s’incrémenter à chaque changement du paquet.

Sous-révision (sub-release) (applicable uniquement aux mises à jours)

Veuillez vous référer la section de nos conventions des mises à jours (en).

Balises

• La balise de l’empaqueteur (Packager) ne doit pas être utilisée dans le fichier Spec. Les identités des empaqueteurs sont évidentes depuis les entrées du journal de modifications (changelog). En évitant d’utiliser la balise « Packager » vous éviter de retrouver des fichiers binaires compilé par quelqu’un d’autre avec votre nom dans les entêtes. Voir aussi Maximum RPM definition of the Packager tag (en). Si vous avez besoin d’inclure des informations à propos de l’empaqueteur dans les RPM que vous construisez, utilisez plutôt %packager dans votre ~/.rpmmacros
• La balise du vendeur (Vendor) ne pas non plus être utilisé. Il est automatiquement réglé par le système de construction (build system).
• Ordinairement, la balise PreReq doit être remplacé par entièrement par Requires. Pour plus d’information voir Maximum RPM fine grained dependencies chapter (en).
• La balise Source informe où trouver la source à l’amont du rpm. Dans la plupart des cas ça doit être le lien internet complet vers l’archive en amont (upstream tarball). La meilleure pratique veut l’utilisation de macros comme %version et %name pour permettre des mises à jours automatiques, mais ce n’est pas nécessaire.

La balise résumée (Summary)

Cette balise décrit en une seule ligne le paquet. De longueur maximum de 79 caractères, elle commence avec une lettre majuscule et non pas avec un espace. Le sommaire doit finir avec un point «. » Si ça vous dérange d’un point de vue grammatical, asseyez-vous, prenez une profonde inspiration et surmontez cette épreuve.

Le nom du paquet ne doit pas être répété dans le résumé. C’est une information redondante et donne un aspect étrange dans certains résultats de programme.

Il doit être adapté à toutes les situations standard et ne pas se préoccuper de contextes spéciaux. Il est utile dans les listes de paquets ordonnées alphabétiquement ou non, comme dans les listes de tous les paquets.

Il doit décrire la fonction principale du paquet et les propriétés particulières de ce paquet pour aider l’utilisateur à comparer des paquets aux noms ou fonctions similaires. Par exemple les deux mots « navigateur web » sont dans les résumés de tous navigateurs we, mais utilisant des adjectifs en plus (comme minimal, complexe, GNOME, KDE, rapide, ou l’auteur etc) aide à spécifier un paquet.

Le résumé doit être bref et précis sans inclure d’information redondante.

Le fichier SPEC du RPM contient uniquement la version anglaise afin de garde la base de donnée RPM petite.

La balise de groupe RPM (RPM Group)

La balise de groupe RPM est utilisé pour des groupes de paquets par leurs types de fonctionnalités qu’ils fournissent, et façonne la liste visible dans rpmdrake. Il est impératif que les groupes gardent leurs titres anglais, vous trouverez la liste de groupes existants à utiliser pour vos paquets sur la page Mageia policy (en). Actuellement la liste est différente de l’originelle inventé par Red Hat, car pour nous, de notre point de vue, elle n’est plus adaptée aux distributions d’aujourd’hui. Vous pouvez encore la trouver ici.

La balise buildRoot

La balise BuildRoot est obsolète et devrait être supprimée là où elle est rencontrée puisse que sa fonctionnalité est directement gérée par rpm dans mageia.

La balise PreReq

Les paquets ne doivent pas utiliser la balise PreReq. À l’époque, pour résoudre le serpent qui se mord la queue dans la récursion de dépendances, cette balise était utilisée pour désigner un « vainqueur » par rapport à ces dépendances et donc déterminer l’ordre de leur installation. Ce cas n’est plus le cas.

La balise dépendances (requires) / dépendances explicites (explicit requires)

Les paquets doivent contenir uniquement des « Requires » (dépendances) si elles sont absolument nécessaires pour que les logiciels fonctionnent correctement. Utilisez des dépendances versionnées au besoin comme expliqué plus loin.

Les paquetages ne doivent pas contenir « explicit Requires » (dépendances explicites) sur des librairies sauf lorsque c’est absolument nécessaire et si tel est le cas il doit y avoir un commentaire le justifiant dans le fichier SPEC.

De manière générale on compte sur RPMbuild pour ajouter automatiquement les dépendances par le SONAME des librairies (le SONAME est le nom de la librairie suivit de sa révision, comme libGL.so.1 est le SONAME de libGL.so.1.2.0), les interpréteurs de script shell, et les modules utilisés par les programmes écrits dans des langages de script populaires comme Perl et Python. Les outils de gestion de paquets les plus récents sont capables de résoudre leurs dépendances et de déterminer quels paquets sont nécessaires pour d’autres. Les dépendances explicites sur le nom du paquet peuvent aider l’utilisateur inexpérimenté qui s’apprête à installer un paquet RPM manuellement, mais, l’histoire a montré que de telles dépendances ajoutaient de la confusion quand, la librairie ou les fichiers étaient déplacés d’un paquet à un autre, quand, les paquets étaient renommés, ou quand, l’un des multiples paquets alternatifs aurait suffi. De plus, dans quelques cas, d’anciennes dépendances explicites sur le nom du paquet imposait des mises à jours et des reconstructions inutiles.

RPMbuild ajoutera automatiquement des dépendances versionnées dans quelques cas : avec le SONAME d’une librairie, le symbole faible de version de glibc, et des versions d’API de Perl ou Python quand elles sont installées comme binaires ou des modules installéesextension versionnées. Des dépendances versionnées explicites sont requises quand on a besoin de permettre des mises à jours correctes vers une révision stable ou de mises à jours d’une révision à une autre, et aident quand on rétro-porte des paquets. Quoi qu’il en soit, elles peuvent périmer, devenir inexacte et superflues après quelque temps et doivent être reconsidérées lorsque ces versions deviennent de l’histoire ancienne. La règle du pouce est d’ajouter (ou de garder) une version explicite s’il est nécessaire pour la mise à jours des deux dernières révisions stables.

Des dépendances versionnées sont particulièrement critiques pour des paquets mis à jours ou rétro-porté à une révision stable. Les utilisateurs pourraient choisir d’installer un sous-ensemble de paquets pendant la mise à jour ou laisser des versions anciennes des paquets installées nécessaires et le résultat est un système non fonctionnel.

Exemple rationnel pour une dépendance versionnée explicite :

# The automatic dependency on libfubar.so.1 is insufficient, # (La dépendance automatique de libfoo.so.1 est insuffisante,) # as we strictly need at least the release that fixes two segfaults. # (car on a besoin au minimum d’une révision qui répare deux erreurs de segmentations.) Requires: libfubar >= 0:1.2.3-7

Exceptions des dépendances/fournisseurs générées automatiquement

Comme tous les fichiers d’un paquet sont scannés automatiquement pour savoir ce dont ils ont besoin ou ce qu’ils fournissent, il est parfois nécessaire de changer quelques fonctions soit d’en exclure. Pour le faire, vous pouvez procéder ainsi :

# Suppress automatically generated Requires for devel packages # (supprime automatiquement les dépendances générées pour) # (le paquet de développement ) %global __requires_exclude devel\(.*\)

ou

---

Cette édition est nécessaire puisque que le code a changé (octobre 2014) This requires some editing as the code has changed (October 2014)

Utilisez maintenant pour les paquets de pear : %global __requires_exclude pear\\(Blowfish/DefaultKey.php\\)

---

# Suppress automatically generated Requires for pear packages # (Supprime les dépendances générées automatiquement pour) # (les paquets de pear) %global __requires_exclude pear(vendor/autoload.php)\\|pear(xmlapi.php)

# we don't want to provide private python extension libs # (Nous ne voulons pas fournir d’extensions privées pour) # (les librairies Python.) %define __provides_exclude_from ^(%{python_sitearch}/.*\\.so\\|%{python3_sitearch}/.*\\.so)$

Vous pouvez aussi voir cette page du wiki de Fedora pour plus d’information à ce sujet.

Débogage des dépendances récursives

Il y a une erreur récurrente lorsque des règles de dépendances sont trop nombreuses et contradictoires. Alors librpm doit briser cette chaîne de dépendances et le fait un peu aléatoirement en ayant un semblant de chaîne puisqu’il est impossible d’en finir lorsqu’il y a ces conflits dans les balises de dépendances.

Il est possible d’utiliser une commande comme « urpmi --debug-librpm --deploops » afin de déboguer ce genre de situations.

Mettre à jour depuis une révision précédente peut être résolu en cassant les boucles de dépendances.

La balise des dépendances de construction (BuildRequires)

Dans le développement et les tests de packages, veuillez vérifier que votre paquet ne manque d’aucune dépendance de construction (BuildRequires) nécessaire. Avoir les dépendances propres pour la construction épargne beaucoup de temps au développeur et aux testeurs ainsi qu’au système de construction, car il ne sera pas nécessaire de chercher manuellement les dépendances manquantes. C’est aussi une sécurité pour la construction du paquet qui n’échouerait pas, mais pour lequel il manquerait des fonctionnalités cruciales. Par exemple, une application graphique pourrait exclure le support PNG après que son script de configuration détecte que libpng n’est pas installé.

Les BuildRequires doivent être listés au moyen d’une seule par ligne pour un maximum de lisibilité; au lieu d’en bourrer plusieurs sur une seule ligne, utilisez une balise BuildRequires par dépendance. Tandis que les RPM peuvent « voir » une très longue ligne de BuildRequires, nous les humain ne le pouvont pas, même si cela rend la spec plus longue, cela la rend plus lisible. Avant d’ajouter des BuildRequires à un quelconque paquet, veuillez vous sentir à l’aise avec les dépendances. Veuillez aussi vérifier que vous n’ajoutez pas de BuildRequires non nécessaire. Si vous ajoutez les BuildRequires au paquet « A » et aussi des dépendances « Requires » sur les paquets. Si le paquet « A » a les dépendances pour la construction et aussi les dépendances au paquet « B » et « C », il est inutile de préciser, d’ajouter ces BuildRequires « B » et « C ». Vous pouvez le vérifier avec urpmq -pd sur le paquet « A ».

Lorsque vous déclarez un requis de construction (BuildRequires), il faut utiliser une fourniture virtuelle (virtual porvides) sans spécification d’architecture. Ces fournitures virtueles indépendantes de l’architecture sont par exemple les %name-devel (qui a été ajouté manuellement conformément à nos conventions sur les librairies(en)) ou pkgconfig(name) (qui est déjà disponible pour plein de paquet, et est généré automatiquement).

Par exemple, n’utilisez pas libsqlite3-devel, mais utilisez soit sqlite3-devel, soit pkgconfig(sqlite3). Vous pouvez vérifier quel produit virtuel un paquet -devel a, avec :

rpm -q --provides lib64sqlite3-devel

qui fournira ce genre de résultat :

libsqlite3-devel = 3.7.6.2-3.mga1 sqlite3-devel = 3.7.6.2-3.mga1 pkgconfig(sqlite3) = 3.7.6.2 devel(libsqlite3(64bit)) lib64sqlite3-devel = 3.7.6.2-3.mga1 lib64sqlite3-devel(x86-64) = 3.7.6.2-3.mga1

Comme vous pouvez le voir, seulement les deux recommandés précédemment ne portent aucune référence à l’architecture contrairement à devel(libsqlite3(64bit)) ou lib64sqlite3-devel(x86-64).

Attention ! Si vous utilisez des binaires comme desktop-file-install vous devez obligatoirement mettre les paquets comme dépendant à la construction qui le contient, sinon le paquet échouera lors de sa construction sur le système de construction de Mageia.

Quand vous construisez un paquet localement, vous pouvez facilement installer les dépendances à la construction du paquet foo avec la commande :

urpmi foo.spec

(ou urpmi --buildrequires foo.spec ou urpmi --buildrequires foo.src.rpm qui serait sa syntaxe la plus correcte.) Cela placera tous les paquets listés dans le fichier spec comme BuildRequires.

Les balises sur les architectures (ExclusiveArch / ExcludeArch / %ifarch / %ifnarch)

N’utilisez ExclusiveArch seulement lorsque vous êtes sûr qu’un paquet ne fonctionne que sur certaines architectures. Pareil pour ExcludeArch, quand vous savez sur quelle architecture il ne fonctionne pas, sans savoir sur quelle architecture il fonctionne.

Pour x86 (i586) la macro à utiliser est %ix86.

%ifarch/%ifnarch doivent être évités autant que possible, au moins pour patcher. En général, vous ne devriez pas appliquer un patch conditionnellement pour une seule architecture. Ceci donnera l’avertissement rpmlint :

%ifarch-applied-patch A patch is applied inside an %ifarch block. Patches must be applied on all architectures and may contain necessary configure and/or code patch to be effective only on a given arch.

(traduction : Un patch est appliqué au sein d’un bloc %ifarch. Les correctifs doivent être appliqués sur toutes les architectures et peuvent contenir les correctifs de configuration et/ou de code nécessaires pour être efficaces uniquement sur une arche donnée.)

La balise sources

Les fichiers sources doivent commencer avec Source0, ne commencez pas avec « Source : » puis « Source1 : ». Même si le paquet a seulement un fichier source, utilisez là encore Source0. Si le fichier source a un lien URL pour le télécharger, il doit être inclus. Dans la plupart des cas, c’est le lien complet de l’archive TAR intégrale en amont (upstream). La meilleure pratique serait d’utiliser des macros comme %version et %name pour ce lien, ce qui pourrait rendre automatique les mises à jour, mais c’est optionnel.

La balise patch (correctif, rustine)

Chaque problème doit être résolu dans un patch séparé. Pour faciliter la maintenance des correctifs, la source du correctif doit être indiquée, surtout si le correctif doit être mis à jour à partir de la même source à l’avenir. Lorsque le correctif est ajouté pour la première fois, la source du correctif doit être indiquée dans le message de validation. Il est également utile d’avoir un commentaire dans le SPEC d’où vient le patch, qui devrait être une URL complète vers l’amont si ce n’est pas évident, et une description de ce que fait le patch en quelques mots simples, si cela ne ressort pas clairement du nom du correctif.

Les correctifs doivent commencer avec le mot clef Patch0 dans le fichier SPEC, comme la balise Source. Les correctifs doivent être nommés de manière très explicite pour indiquer clairement quelle version du logiciel le correctif a été initialement généré ou appliqué. Enfin, les noms des rustines suivent généralement la convention [nom_du_paquet]-[version]-[description].[suffix du nom de fichier] où :

• [nom_du_paquet] est le nom du paquet auquel le correctif s’applique, comme « shadow-utils » ou « gnupg »
• [version] est la version du programme pour lequel le correctif a été développé, comme 1.0. Si une rustine est rediffusée, car la rustine précédente ne s’applique pas à la nouvelle version, une nouvelle rustine doit alors être crée avec un nom approprié. C’est inapproprié de rediffuser foo-1.0-linking-fix.patch pour foo-1.2 et de continuer d’utiliser le même nom de rustine. La nouvelle rustine doit être nommée foo-1.2-linking-fix.patch. Pour des raisons historiques, les rustines doivent être mises sur svn ; au lieu de faire « svn rm foo-1.0-linking-fix.patch » et « svn add foo-1.2-linking-fix.patch », la rustine originale doit être déplacée et après la nouvelle rustine dérivée doit être copié et envoyé; par exemple « svn mv foo-1.0-linking-fix.patch foo-1.2-linking-fix.patch; svn commit »
• [description] est une brève discription du but de la rustine
• [suffix du nom de fichier] Normalement c’est .patch et quelques fois .diff lorsque les rustines sont réutilisées en amont.

Les rustines devraient être au format unifié (diff -u) et à appliquer avec un niveau d’arborescence 1 dans le fichier spec (%patch -p1, voir l’option -p avec $man patch). Les seules exceptions sont les rustines obtenues d’un autre site de source primaire. Le nom original, le suffixe et le format sont alors préservés. Chaque rustine doit être conservé au format plein texte et non compressé, ça permet leur utilisation avec l’interface web de SVN par exemple.

Pour les rustines à appliquer, elles devraient être mentionnées dans %prep en dessous de %setup, et devrait être fait comme présenté ci-dessous :

%patch0 -p1 -b .foobar

• -p1 est le niveau d’arborescence, relatif à partir d’où le patch est appliqué
• -b est le suffixe qui est ajouté au fichier de sauvegarde que la commande créer, dans ce cas .foobar, ceci doit être similaire ou découle de la partie [description] de la rustine.

Pour confectionner des rustines, vous pouvez vous faciliter le travail en utilisant quelque chose comme http://labix.org/patcher.

• Utiliser %apply_patches

On peut l’utiliser pour remplacer toutes les lignes %patchN dans %prep et gagner de l’espace dans le fichier spec (spécialement dans un paquet avec plein de rustines de l’amont) puisse qu’il appliquera toutes les rustines avec une commande. Quoi qu’il en soit, pour que ça fonctionne toutes les rustines doivent être -p1 et les mots clefs de définition des PatchN: doivent être placées immédiatement après les mots clefs de définition sourceN: du fichier spec, sinon ils seront silencieusement ignorés (aucun message d’erreur durant la construction) alors soyez prudent. Autrement, la macro %autopatch -p1 peut être utilisée, elle fonctionne essentiellement de la même manière. C’est une nouvelle macro standard venue de l’amont RPM et donne ainsi une meilleure compatibilité avec d’autres distributions.

La balise %clean

La balise %clean est obsolette et devrait être supprimée systématiquement si elle est rencontrée, car sa fonctionnalité dans Mageia est directement gérée avec rpm.

La documentation

Tout document pertinente inclut dans les sources doit être inclus dans le paquet. Les documents non pertinents sont les instructions de construction, l’omniprésent fichier INSTALL contenant des instructions générique de construction et les documents pour les systèmes autres que Linux par exemple README.MSDOS. Faites attention à quel sous-paquet vous ajoutez les documents, par exemple les documents pour une API appartiennent au sous-paquet de développement -devel et non pas au principal. Ou, s’il y a beaucoup de document, il est possible de les rassembler en un sous-paquet séparé. Dans ce cas, il est recommandé d’utiliser le suffixe *-doc au nom du sous-paquet et Documentation comme valeur de la balise Group.

Si le paquet inclut quelque chose comme %doc, il ne doit pas affecter l’exécution et le déroulement du logiciel. En résumé : si c’est dans %doc, le programme doit fonctionner proprement s’il n’est pas présent.

Vérifiez que les fichiers des documents ont les permissions permettant d’être lus par les utilisateurs normaux.

Quand les pages Man sont uniquement disponibles en anglais, installez les décompressés dans %{buildroot}%{_mandir}/manX/ (où X est le numéro de section approprié). Ils seront automatiquement compressés avant d’être empaqueté, ainsi ils doivent être inscrits dans la section %files avec un caractère jocker, ex : %{_mandir}/man1/xyzzy.1*. Les pages Man obtiendront automatiquement l’attribut %doc, alors ne les ajoutez pas explicitement.

Paquet de développement

Si le logiciel qui sera empaqueté contient des fichiers prévus uniquement pour du développement, ces fichiers doivent être placés dans un sous-paquet -devel. Les exemples suivant sont des types de fichiers qui doivent-être placé dans ce sous-paquet -devel :

• Les fichiers d’entête (comme les fichiers .h)
• les librairies partagées non versionnées (comme libfoo.so). Tandis que les librairies versionnées (comme libfoo.so.3, libfoo.so.3.0.0) ne doivent pas être dans un -devel.

Une bonne règle est, si le fichier est utilisé pour du développement et n’est pas nécessaire dans le paquet de base du logiciel pour fonctionner proprement, il doit aller dans -devel.

Les fichiers .a et .la doivent généralement pas être inclus tout court. Ils sont seulement nécessaires quand on souhaite lier un programme avec des librairies statiques (le programme inclut la librairie en lui-même ainsi la librairie n’est plus nécessaire lors de l’exécution), ce qui n’est généralement pas le cas avec Mageia. Les archives libtool, les fichiers foo.la ne doivent pas être inclus. Des paquets utilisant libtool les installeront par défaut même si vous les configurez avec --disable-static, alors ils seront à supprimer avec l’emballage du paquet. Dû à des bogues dans des versions précédentes de libtool ou des bogues dans les programmes qui l’utilisent, parfois il n’est pas toujours possible de supprimer simplement les fichiers *.la sans avoir à modifier le programme. Dans la plupart des cas, il est raisonnable et facile de travailler avec l’amont pour corriger ces problèmes. Notez que si vous mettez à jour une librairie vers une version stable (et non une version de développement) et que le paquet contient déjà des fichiers *.la, supprimer ces fichiers *.la doit être traité comme un changement d’API/ABI -- ex : les supprimer change l’interface que la librairie donne au reste du monde ne doit pas être pris à la légère.

Dépendant du paquet de base

Les paquets de développement doivent dépendre des paquets de base en utilisant une dépendance entièrement versionnée :

Requires: %{name} = %{version}-%{release}

Habituellement, les sous-paquet autre que -devel devraient aussi être dépendants du paquet de base aussi en utilisant une dépendance entièrement versionnée.

Fichiers Pkgconfig

Le placement des fichiers pkgconfig(.pc) dépend de leurs usages. Depuis qu’ils sont presque toujours utilisés à des fins de développement, ils sont à placer dans un paquet -devel. Une exception raisonnable est lorsque le paquet principal lui-même est un outil de développement qui n’est pas installé dans l’environnement d’exécution de l’utilisateur, comme gcc ou gdb.

Bibliothèques partagées

Chaque fois que c’est possible (et faisable), les paquets Mageia contenant des bibliothèques devraient les compiler en tant que bibliothèques partagées.

Un ldconfig n’est plus nécessaire pour les librairies dans %post ni %postun, c’est automatiquement géré par le RPM filetriggers. Si c’est le cas, veuillez enlever les appels à ldconfig et si c’était l’unique but de %post / %postun, alors supprimez entièrement ces sections vides.

Consulter Libraries policy (en) pour plus de détails sur la façon de créer des bibliothèques pour les paquetages.

Fichiers de configuration

Les fichiers de configuration doivent être marqués comme tel dans les paquets.

Comme bonne règle, utiliser %config(noreplace) à la place d’un simple %config à moins que vous pensiez que faire ainsi brisera les choses. En d’autres mots, réfléchissez bien avant d’écraser un fichier de configuration local par la mise à jours du paquet. Un exemple quand il ne faut pas utiliser noreplace, quand un fichier de configuration d’un paquet change à tel point que la nouvelle version du paquet ne fonctionnerait plus avec l’ancien fichier de configuration. Dès que vous utilisez un simple %config, veuillez ajouter un bref commentaire dans le fichier spec expliquant pourquoi.

Veuillez ne pas utiliser %config ou %config(replace) dans /usr. /usr n’est censé contenir de fichier de configuration sur Mageia.

Gestion de Service / Initscripts

Depuis Mageia 3, systemd est le seul système d’initialisation offert, cependant, il supporte encore les scripts d’initialisations de style systemV avec la mise en garde qu’ils doivent contenir un entête LSB valide pour permettre d’extraire les informations sur les dépendances proprement.

Mageia 2 supportait autant le démarrage avec SystemV et systemd, et dépendait autant de scripts d’initialisation de style SystemV et optionnelement d’une unité systemd.

Mageia 1 ne supportait que SystemV.

Pour plus d’information sur l’empaquetage des services, veuillez voir les consignes d’empaquetage des services (en).

Fichiers desktop

Si un paquet contient une application avec interface graphique, alors il est nécessaire aussi d’installer proprement un fichier .desktop. Une application avec interface graphique défini toutes application qui dessine une fenêtre X et s’execute depuis cette fenêtre. Le fichier .desktop installé DOIT suivre les spécifications d’entrer desktop (en), avec une attention particulière de bien valider correctement les entrées Name, GenericName, Categories et StartupNotify. Veuillez toujours faire valider le fichier .desktop avec le logiciel desktop-file-validate du paquet desktop-file-utils.

La clé Icon des fichiers Desktop

La clef Icon peut être uniquement spécifié d’une manière : * Nom court sans chemin ni extension au nom : Icon=comical

Le nom court sans extension permet pour d’utiliser des thèmes (Par défaut on suppose que l’extension est .png, puis on essaie avec .svg et enfin .xpm)

Création du fichier .desktop

Si le paquet n’en contient pas déjà un ni installe son propre fichier .desktop, il est nécessaire d’en créer un. Vous pouvez générer un fichier .desktop comme une source : (comme Source3: %{name}.desktop) ou en le générant dans le fichier spec à « here document ». Voyez ci-dessous en exemple la création par « here document », la partie verte est le contenu du fichier .desktop.

mkdir -p %{buildroot}%{_datadir}/applications cat > %{buildroot}%{_datadir}/applications/%{name}.desktop << EOF <span style="color:#0c0;">[Desktop Entry] Name=Ginkgo Comment=Ginkgo is a graphical front-end for Nepomuk Exec=%{_bindir}/%{name} Icon=nepomuk Type=Application Categories=Utility;KDE;Qt;</span> EOF

Régionnaliser les fichiers .desktop

Les valeurs de Name et de GenericName sont affichés comme légende à l’icône du bureau, ainsi elles doivent s’accorder avec la régionnalisation conformément aux spécifications des entrées Desktop. La plupart du temps, seulement le code du langage (fr, de, etc) ou l’ensemble codes langage/pays sont nécessaires pour sélectionner la régionnalisation du système. Par exemple :

[Desktop Entry] Type=Application Name=Clocks Name[de]=Uhrzeit Name[es]=Relojes Name[fr]=Horloges Name[pt_BR]=Relógios Name[zh_CN]=时钟

Dans le fichier .desktop ci-dessus, [de] spécifier la langue allemande, recouvrant tous les pays dont la langue est l’allemand, aussi bien de_DE l’Allemagne que de_AT l’Autriche.

Note : comme l’ensemble langage/pays (ex : pt_BR est plus spécifique que le code langage (ex : pt), une chaine de caractère pour les lieux pt_BR ne sera pas utilisé pour les lieux de la langue portugaise (pt). Si une chaine est appropriée pour tous les lieux dont la langue est le portugais, utilisez "Name[pt]" à la place.

Utilisation de desktop-file-install

desktop-file-install DOIT être utilisé s’il y a des changements désirés sur un fichier .desktop délivré par l’amont (comme l’ajout ou la suppression d’une catégorie, etc). Note : Les options d’édition limitées disponibles peuvent être demandées via desktop-file-install --help-edit ou desktop-file-install --help-all

Voici quelques usages :

desktop-file-install --vendor="%{_real_vendor}" \ --remove-category="Application" \ --add-category="Settings;HardwareSettings;" \ --dir %{buildroot}%{_datadir}/applications %{buildroot}%{_datadir}/applications/%{name}.desktop

desktop-file-install --vendor="%{_real_vendor}" \ --dir=%{buildroot}%{_datadir}/applications \ --remove-category='Application' \ --remove-category='Utility' \ --add-category='System' \ --add-category='Settings' \ --add-category='Printing' \ --add-category='Qt' \ --add-category='HardwareSettings' \ --add-category='X-Mageia-CrossDesktop' \ --remove-key='Version' \ %{buildroot}%{_datadir}/applications/hplip.desktop

L’installation du fichier .desktop sur le system cible ne doit plus être géré manuellement comme précédemment dans %post/%postun, maintenant, c’est automatiquement géré avec RPM filetriggers (en). Veuillez juste vérifier que tous les fichiers .desktop que vous souhaitez installer sont correctes et valides comme souligné au par avant.

Catégorie spécial MandrivaLinux

Dans plusieurs paquets importés de Mandriva, les fichiers .desktop ont des entrées de catégories "X-MandrivaLinux" obsolètes. Elles avaient leur utilisé lors de la transition du système de menu Debian vers le système de menu Freedesktop XDG, donc obsolètes et sont à remplacer par la catégorie standard de Freedesktop. Vous les trouverez dans la spécification de Freedesktop.

La seule catégorie de Mandriva qui a son équivalent encore sur Mageia est X-MandrivaLinux-CrossDesktop. Cette catégorie est prévue pour les applications de type « kit d’outils » (comme GTK, QT, KDE) dans leur fichier desktop (et seront donc affichés dans « plus » de sous-menu dans d’autre environnement) quand on ne veut pas qu’ils aillent dans CrossDesktop. Pour une référence, veuillez-vous référer au rapport de bogue : Bug 2449 - X-MandrivaLinux-* should be dropped.

Voici un exemple comment ça doit être fait. Le fichier totem.desktop du lecteur multimédia Totem contient :

Categories=GTK;GNOME;AudioVideo;Player;Video;X-MandrivaLinux-CrossDesktop;X-MandrivaLinux-Multimedia-Video;

Ainsi X-MandrivaLinux-CrossDesktop doit être remplacé par X-Mageia-CrossDesktop (ou on peut supprimer les catégories GTK et GNOME du fichier desktop, mais ceci supprimerait aussi des informations potentiellement intéressantes pour quelques environnements graphiques).

Aussi, X-MandrivaLinux-Multimedia-Video est une catégorie obsolète et définitivement ne doit plus être utilisée, à la place la catégorie est remplacée par la catégorie principale de Freedesktop AudioVideo et complété au moins par une catégorie additionnelle de http://standards.freedesktop.org/menu-spec/latest/apa.html. Comme c’est déjà le cas (AudioVideo;Player;Video; voir ci-dessus) cette catégorie X-MandrivaLinux doit simplement être enlevée.

Macros vs variables

%{buildroot} et %{optflags} vs $RPM_BUILD_ROOT et $RPM_OPT_FLAGS De manière générale il y a deux style pour définir le BuildRoot du RPM et les drapeaux d’optimisation dans le fichier spec :

	style macro	variable style
Build Root	%{buildroot}	$RPM_BUILD_ROOT
Opt. Flags	%{optflags}	$RPM_OPT_FLAGS

Conformément à nos consignes de syntaxe des SPEC (en) les variables qui sont réellement des définitions tel que $RPM_OPT_FLAGS ou $RPM_BUILD_ROOT ne doivent pas être utilisées. Les macros comme %{optflags} et %{buildroot} doivent les remplacer. Gardez les variables "$*" pour les constructions du shell et non pas pour les définitions de base d’un RPM.

Tenue des fichiers d’internationalisation

Les fichiers régionaux (autrement dénommé Localizations (en francais, régionnalisation), son abréviation est l10n, ou Internationalisation (i18n), le numéro dans les abréviations correspond au nombre de lettres omises), sont compilés dans des fichiers .mo. Cette section n’est pas à propos des pages Man.

(Si un paquet inclut des traductions, il n’est plus nécessaire d’ajouter gettext comme dépendance de construction (BuildRequire), car gettext est déjà présent dans l’environnement de construction.)

Mageia inclut une macro rpm nommée %find_lang. Cette macro trouvera tous les fichiers régionaux qui appartiennent au paquet (par nom), et placera cette liste dans un fichier. Vous pouvez alors utiliser ce fichier pour inclure les fichiers régionaux. %find_lang doit être exécuté dans la section %install de votre fichier spec, après que tous les fichiers ont été installés dans le buildroot. La syntaxe correcte pour %find_lang est habituellement :

%find_lang %{name}

Dans certains cas, l’application utilisera des « name » différents pour des régions. Vous devriez jeter un coup d’œil aux fichiers régionaux pour connaitre leur dénomination. S’ils sont nommés myapp.mo, alors vous devez donner myapp à %find_lang à la place de %{name}. Après l’exécution de %find_lang, un fichier sera généré dans le répertoire courant (par défaut la racine des sources). Ce fichier prendra un nom basé sur les options que vous aurez données à la macro %find_lang. Habituellement, il sera nommé %{name}.lang. Vous devriez alors utiliser ce fichier dans la liste %files pour ajouter les fichiers régionaux détectés par %find_lang. Pour ce faire, vous devriez l’inclure avec le paramètre -f à %files.

%files -f %{name}.lang %{_bindir}/foobar …

Si le paramètre -f est déjà utilisé pour la section %files où vous devriez ajouter les fichiers régionaux, ajoutez simplement le contenu de %{name}.lang après le fichier utilisant déjà le paramètre -f. (Notez qu’uniquement un fichier peut être utilisé avec %files -f.)

Pourquoi avons-nous besoin d’utiliser %find_lang?

L’utilisation de %find_lang aide à garder un fichier de spécification simple et aide à éviter quelques erreurs d’empaquetage.

• Les paquets qui utilisent %{_datadir}/* pour extraire tous les fichiers régionaux en une ligne extrait aussi le propriétaire des répertoires locaux, ce qui n’est pas permis.
• La plupart des paquets qui ont des fichiers régionaux en ont beaucoup. Utiliser %find_lang est bien plus conviviale (utilisation, clarté…) dans le fichier de spécification que d’avoir à écrire :

%{_datadir}/locale/ar/LC_MESSAGES/%{name}.mo %{_datadir}/locale/be/LC_MESSAGES/%{name}.mo %{_datadir}/locale/cs/LC_MESSAGES/%{name}.mo %{_datadir}/locale/de/LC_MESSAGES/%{name}.mo %{_datadir}/locale/es/LC_MESSAGES/%{name}.mo …

• Comme de nouveaux fichiers régionaux peuvent apparaitrent dans de futures versions, %find_lang les inclura automatiquement à son exécution et vous évitera de mettre à jour le fichier de spécification plus que nécessaire.

Gardez à l’esprit que l’usage de %find_lang dans un paquet contenant des fichiers régionaux est un IMPÉRATIF.

Scriptlets

Une grande attention doit être porté lors de l’utilisation de scriptlet dans les paquets de Mageia. Si des scriptlets sont utilisés, ceux-ci doivent être sains.

Prérequis des Scriptlets N’utilisez pas le style de notation Requires(pre,post) pour les dépendances aux scriptlets en raison de deux bugs dans RPM. À la place, vous devriez les séparer comme ceci :

Requires (pre): … Requires (post): …

Pour plus d’information, veuillez voir www.redhat.com .

Exécution de scriptlets uniquement dans certaines situations Lorsque la commande rpm exécute un scriptlet d’un paquet, l’action associée (quelle soit une installation, un effaçage, une mise à jour ou une réinstallation) est donnée par un entier en paramètre du script en question, en suivant les codes suivant :

macro	install	erase	upgrade	reinstall
%pre	1	-	2	2
%post	1	-	2	2
%preun	-	0	1	-
%postun	-	0	1	-

Ceci signifie par exemple qu’un paquet qui installe un script d’initialisation avec la commande chkconfig doit le désinstaller uniquement avec « erase » et non avec une mise à jour avec le snippet suivant : This means that for example a package that installs an init script with the chkconfig command should uninstall it only on erase and not upgrade with the following snippet:

%preun if [ $1 -eq 0 ] ; then /sbin/chkconfig --del %{name} fi

Veuillez aussi voir /usr/share/doc/rpm-*/triggers, qui donne une définition plus formelle et générale à propos des valeurs entières passé aux scripts.

Les scriplets sont autorisés d’écrire uniquement dans certains dossiers Les scripts de construction des paquets (%prep, %build, %install, %check et %clean) peuvent gérer seulement les fichiers (créer, modifier, supprimer) sous %{buildroot}, %{_builddir} et les répertoires temporaires valides comme /tmp, /var/tmp (ou $TMPDIR, %{_tmppath} comme définit par le processus rpmbuild), conformément au tableau suivant :

	/tmp, /var/tmp, $TMPDIR, %{_tmppath}	%{_builddir}	%{buildroot}
%prep	Oui	Oui	Non
%build	Oui	Oui	Non
%install	Oui	Oui	Oui
%check	Oui	Oui	Non
%clean	Oui	Oui	Oui

Clarification complémentaire : Ceci reste vrai quel que soit l’UID du constructeur.

L’usage de la balise Epoch

La balise Epoch dans RPM doit être utilisée qu’en dernier recours, et doit être évitée autant que possible. Quoi qu’il en soit, il est parfois nécessaire d’utiliser Epoch pour gérer un changement de version de l’amont ou de faciliter la transition d’un dépôt tiers.

Créer un paquet à partir de zéro

Si vous voulez créer un paquet de zéro, voici le squelette d’un fichier SPEC où vous n’avez qu’à remplacer foo avec vos propres valeurs conformément à ce guide.

Name: foo Version: 1.0 Release: %mkrel 1 Summary: foo License: foo Group: foo URL: foo Source0: %name-%version.tar.bz2 %description foo %prep %setup -q %build %configure2_5x %make %install %makeinstall %find_lang %name %files -n %name

Modifier un paquet existant

Si pour créer un paquet mageia basé sur un paquet existant d’une autre distribution, soyez sûr d’avoir vérifié l’exactitude du paquet et de son fichier spec pour comprendre exactement ce qui a été fait pour construire le paquet. Ne soumettez pas un paquet sans savoir ce que les étranges commandes d’apparences innocentes font.

Vous devez particulièrement :

• Vous assurer que l’archive est autonome. Une archive ne doit pas contenir de lien symbolique qui aurait une référence à l’extérieur de la racine de l’archive
• vérifier toutes les sources et correctifs, supprimez ceux qui :
  • sont relié à des plateformes que nous ne supportons pas (ex : sparc, ia64, ppc…)
  • ou implémenter des fonctionnalités que nous ne supportons pas (ex : selinux)
  • Lire tous les correctifs et comprenez ce qu’ils font. Si ce n’est pas nécessaire, ajouter à l’entête du correctif une explication justifiant pourquoi.
• Vérifier que la licence précisée dans le fichier spec correspond bien à la licence actuelle du logiciel. Nous conseillons pour ça de faire un grep sur tous les fichiers sources et vérifier les informations des licences.
• parcourez les sommaires et les descriptions pour des fautes de frappes et bizarreries (voir Sommaire et description),
• assurez-vous que la bonne racine de construction est utilisée,
• assurez-vous de la consistance de l’usage des macros et de leur existence dans Mageia (voir Macros)

Gardez les vieilles entrées dans les registres de changement pour créditer l’auteur originel. Les entrées âgées de plusieurs années ou référençant une ancienne version du logiciel peuvent être effacées. Si au final vous avez radicalement changé ou réécrit la majorité du fichier spec, jugée par vous-même si vous démarrer de zéro un nouveau journal de modifications (changelog).

Journal des modifications (Changelogs)

Cette section décrit les consignes chez Mageia concernant le journal de modifications des RPM nommé « changelogs ». (Le journal de modifications original des sources du logiciel en amont ne sont pas affectés par ces consignes.)

Lorsque vous importez un paquet, pensez à importer le changelog !

Veuillez considérer que « l’utilisateur final avec quelques compétences techniques » devrait être capable de comprendre un registre de changement RPM. Les entrées du registre doivent-être d’ordre anti-chronologique : les nouvelles entrées du journal de modifications sont inscrites au-dessus des anciennes entrées de la liste, la première entrée est la plus récente.

Gardez à l’esprit que le journal de modifications de Mageia est automatiquement analysé pour préparer la note de version de la distribution, pour les rapports de bogues et pour les CVEs ainsi une entrée malformée ne sera pas lue correctement.

Informations générales

• Les registres de changements sont stockés dans les registres des commits sur SVN, mais ils doivent tout de même être considérés comme une part de la spec final quand ils sont soumis sur SVN (voir en dessous)
• La section %changelog ne doit pas être utilisé dans le fichier .spec puisse que les registres des commits svn produisent le journal de modifications du RPM pour la construction
• On écrit un message lors de la soumission lorsqu’il y a des changements, soit par svn ci ou mgarepo ci avec l’option -m '- ici le message de soumission'
• Fournissez un message de soumission significatif et détaillé et rendez-le suffisamment explicite afin que les personnes qui viendront plus tard n'aient pas besoin de regarder une liste de changements pour comprendre ce qui s'est réellement passé.

• Voici un mauvais exemple :

- fixed foo

Ceci ne dit rien à personne et après un an, quelle que soit la personne qui ait fait ce genre de soumission n’a plus aucune idée des changements sur cette soumission.

• Voici un bon exemple :

- rediffed description.patch to fix foo - added foo-manpages.tar.bz2 to provide such and such for foo - dropped cvsfix32.patch; merged upstream

Ce dernier exemple est bien plus parlant sur ce qui s’est réellement passé. Notez que les fichiers sources doivent être référés par leur nom entier (sur l’exemple précédent foo-manages.tar.gz, mais pas « S2"3 ou « Source23 » ou autre). Il n’est pas nécessaire de référer les correctifs par leur nom complet, mais peuvent être référé par la portion de leur « description ». Par exemple, le premier commentaire est « rediffed description.patch to fix foo" et description.patch est noté. Les correctifs peuvent en réalité être nommés foo-1.2-mga-description.patch ; le préfix (foo-1.2-mga) peut être omis puisse qu’il est simple de le retrouver par sa simple description quel correctif a changé/ajouté ou supprimer quelque chose. Si le nom du correctif n’est pas unique (ex : il y a foo-1.2-mga-description.patch et foo-1.0-cvs-description.patch), alors l’un des deux noms de correctifs peut (et probablement doit) être changé ou le nom tout entier du correctif doit être noté dans le journal de modifications. Ne référez par les fichiers sources ou les correctifs par leur numéro (ex S23 ou P12) puisse que les correctifs et les fichiers sources peuvent être renumérotés parfois ainsi il n’est pas exclu que ça ne reste pas consistant.

• Quand vous ajoutez un message de soumission sur plusieurs lignes, chaque entrée différente doivent commencer avec le caractère 'moins' comme :

- Bumped release - Added foo.patch

Ceci est optionnel pour les messages sur une seule ligne puisque dans ce cas, il est ajouté s’il n’est pas présent. Pour créer un message sur plusieurs lignes, laissez simplement la première ligne dans un état indéterminé (sans signe de citation final), appuyez sur [entrer], et continuez à écrire sur la ligne en dessous. Finissez la dernière ligne avec le signe de fin de citation. Ou encore écrivez un message de soumission dans un fichier et incorporez lors de la ligne de commande avec l’option -F pour svn ci / mgarepo ci.

Références externes

Toutes références externes (numéro de bogue etc) doivent être de cette forme :

"(" + code de référence externe + numéro de bogue +")"

Actuellement défini :

• Mageia Bugs : mga#
• Common Vulnerability / Exposure : CVE

Les numéros de bogue dans les registres de changements

Durant la maintenance de la distribution, chaque changement doit être marché avec le numéro de bogue correspondant. Normalement ceci doit être un numéro de https://bugs.mageia.org/. Ajoutez une entrée avec le numéro de bogue de bugzilla et une courte description du résumé du bogue. Par exemple :

- Removed invalid desktop Category « Application » ({{bug-fr|4654}}). - Symlink icon to pixmaps dir (mga#2108) - Added gnome-ui-properties to control-center ({{bug-fr|1960}}).

Les nouveaux paquets reliés à une nouvelle fonctionnalité seront référé aussi avec le numéro de bogue correspondant sur bugzilla, par exemple :

- Adding Qt Contacts support (mga#8011)

Le numéro de CVE dans le registre de changement Comme avec le numéro de bogue : ajoutez une courte description (normalement le résumé de CVE doit être suffisant), les numéros de bugzilla et de CVE au journal de modifications et aussi le nom et l’origine du correctif qui répare ce CVE. Par exemple :

- fix CVE-2012-1234, denial of service through user stupidity (fix-cve-2012-1234.patch, from upstream).

Modifications du fichier de spécifications

Soyez aussi précis que possible ! Ceci est d’autant plus important si vous supprimez quelque chose du fichier spec.

• Supprimer du code source originel doit être déclaré dans le fichier spec avec un commentaire ("Useful for FreeBSD only" par exemple) - il n’est pas nécessaire de répéter le commentaire dans le fichier de spécification.
• Les commandes supplémentaires (par exemple durant %install) peuvent être illustrées avec un court commentaire dans le fichier de spécification.
• Ajouter/supprimer des paquets de Requires/Provides doit être décrit dans le journal de modifications.
• Une chose qui ne doit pas être faite sans en avertir avec le mainteneur avant de manipuler, est de ré-indenter quelques parties du fichier SPEC. Quoique, seulement les petits changements dans le fichier spec (comme le changement d’une tabulation par deux entre deux balises du préambule et des valeurs) la différence qui est produite par ça sera énorme.

Modifications du code source

Commentez les changements les plus importants, mais limitez la verbosité.

• Regardez dans le journal de modifications et sélectionnez les changements les plus importants pour la distribution (les changements pour d’autres systèmes d’exploitations ne sont pas fondamentaux). Incluez ce qui a changé dans la nouvelle version, habituellement, le niveau de détail du fichier NEWS ; les fichiers des registres des changements sont généralement trop longs. Plus de 10-15 lignes ne sont pas nécessaires pour décrire les changements les plus importants.
• Arrangez les changements originaux derrière l’information de mise à jour de version. Exemple :

- Update to 1.3.2: + fixes memory leak in import function + new API command: unlock_client() + the following bugs are closed by this new upstream release: ++ ............ [mga:332] ++ ............ [mga:337] - split of devel package

• si l’amont ne produit pas un registre de changements plein de sens, alors faites seulement de votre mieux. Ne perdez pas trop de temps à ça.
• Si l’archive de l’amont n’a vraiment aucun registre de changement excepté un numéro de version différent, ajoutez simplement le numéro de version dans le journal de modifications fera l’affaire. C’est pareil pour les paquets qui ne contiennent juste quelques graphiques ou thèmes (sauf si l’amont fourni déjà quelque chose qui convient). Si les changements de l’amont consistent juste à « mise à jour des traductions » ou « réparation que quelques bogues », rien que ça suffise pour l’entrée du journal de modifications (à moins que ces correctifs contiennent quelque chose que vous trouvez en valoir la peine).

Empaquetage des bibliothèques statiques

Les paquets incluant des bibliothèques devraient exclure celles qui sont statiques dans la mesure du possible (par exemple en configurant avec --disable-static). Les bibliothèques logicielles statiques devraient être incluses uniquement dans des circonstances exceptionnelles. Les logiciels qui sont liés aux bibliothèques statiques devraient autant que possible être liés aux versions partagées des bibliothèques.

Les fichiers .a et .la ne devraient généralement pas être inclus nulle part. Ils sont utiles uniquement lorsque quelqu’un veut lier statiquement un programme à une bibliothèque (par exemple inclure la bibliothèque dans le binaire du programme lui-même, de cette manière la bibliothèque n’est plus nécessaire lors de l’exécution du programme), ce qui n’est généralement pas le cas dans Mageia. Les archives Libtool, les fichiers foo.la ne doivent pas être inclus. Les paquets utilisant libtool l’installeront par défaut même si vous spécifiez --disable-static dans la configuration, alors ils seront à supprimer avant l’empaquetage. À cause de bogues dans les anciennes versions de libtool ou de bogues dans les programmes qui l’utilisent, parfois il n’est pas possible de supprimer les fichiers .la sans modifier le programme. Dans la plupart des cas, il est facile de travailler de concours avec l’amont du logiciel pour régler ces problèmes. Notez que si vous chargez une bibliothèque dans sa version stage (pas en développement) et que le paquet contiennent déjà des fichiers .la, les supprimer doit être considéré comment un changement API/ABI -- c’est-à-dire, les supprimer change l’interface que la bibliothèque donne au reste du monde et ne doit pas être entrepris à la légère.

Empaquetage des bibliothèques statiques

• En général, les empaqueteurs sont fortement découragés à envoyer des bibliothèques statiques à moins qu’une irrésistible raison existe.

• Nous voulons être en mesure de traquer quels paquets utilisent des bibliothèquess statiques (comme ça, nous pouvons trouver quels paquets il est nécessaire de reconstruire au cas où un défaut de sécurité dans une bibliothèque statique est réglé par exemple). Il y a deux cas où une bibliothèque statique est empaqueté :

1. bibliothèque statique et bibliothèque partagé Dans ce cas, la bibliothèque statique doit être placée dans un sous-paquet *-statis-devel. Séparer les bibliothèques statiques des autres ficheirs de développement dans un *-devel nous permet de traquer cet usage en vérifiant quels paquets dépendent pour leur construction BuildRequire le paquet *-static-devel. L’intention est, lorsqu’il est possible, d’éloigner ces paquets de l’utilisation des bibliothèques statiques vers les bibliothèques partagées.
2. bibliothèques statiques uniquement. Quand un paquet fournit uniquement des bibliothèques statiques, vous pouvez placer tous les fichiers de bibliothèques statiques dans un sous-paquet *-devel.

• Si (et seulement si) un paquet à une bibliothèque partagée qui requière une bibliothèque statique pour être fonctionnelle, les bibliothèques statiques peuvent être incluses dans un sous-paquet *-devel.

Lier statiquement les exécutables

• La liaison statique est une exception spéciale et doit être décidée au cas par cas. L’empaqueteur doit fournir une justification de la liaison statique, pour obtenir une approbation.

Rendre un paquet obsolète

Lorsqu’un paquet devient inutile dans la distribution, il doit être rendu obsolète ou supprimé de la cauldron/du chaudron.

Pour rendre obsolète et supprimer un paquet du chaudron :

• Sur SVN, déplacer le paquet dans le répertoire svn+ssh://svn.mageia.org/svn/packages/obsolete/ (veuillez aussi voir Comment abandonner un paquet depuis SVN (en)).
• Si un paquet est remplacé par un autre qui fourni les mêmes fonctionnalités, ajoutez-le comme obsolète dans un nouveau paquet. Utilisez des obsolètes versionnés est recommandé (Obsolète : foo < dernière version du chaudron + 1) - Ceci s’applique pour tous les sous-paquets qui devraient être obsolètes !
• Si un paquet n’est pas remplacé par un autre et est simplement abandonné, rendez-le obsolète par le paquet task-obsolete. N’oubliez pas d’ajouter un commentaire avec la raison de l’obsolescence ou un lien vers la discussion de la liste de diffusion expliquant les raisons.). Utiliser des obsolètes versionnés est recommandé (Obsolète : foo < dernière version du chaudron +1) - ceci s’applique pour tous les sous-paquets qui devraient être obsolètes !

Quand un paquet est rendu obsolète par un autre paquet, il sera automatiquement supprimé des dépôts du chaudron.

Ceci a été importé depuis MeeGo wiki sous licence CC-By 3.0
Comme le wiki n’existe plus, regardez sa version archivée : http://wayback.archive.org/web/20130903235324/http://wiki.meego.com/Main_Page

Langages de programmation spécifiques

Voir https://en.opensuse.org/openSUSE:Packaging_nodejs (en)

Retour au Portail d'information de l'équipe de construction des paquets.