From Mageia wiki
Jump to: navigation, search
Drakconf multiflag.png
Autres langues

English ; Français ;

Accueil [en] Accueil Équipes Packageurs Consignes


Warning.png
Warning!
Cette page est une traduction non relue d'une page est en cours d'élaboration qui doit être réadapté à la politique d'empaquetage de Mageia. N'hésitez pas à la relire et la corriger. Les passages en Italique sont à revoir dans la version originale anglaise.


Contents

Consignes d'empaquetage de Mageia

Ces consigues sont basées sur les consignes de Fedora, OpenSUSE, Meego et d'autres distributions.

Maintenir un paquet

Tous les paquet 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 responsable et s'assure que :

  • son paquet est à jour avec les dernières sources en amont (upstream)
  • son paquet est toujours construit dans le système d'empaquetage de Mageia et répare les échecs lorsqu'elles ont lieux
  • 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 à jours de sécurité critiques
  • elle/il fournit les informations à propos des changement majeur aux autres empaqueteurs (packagers) et mainteneurs (maintainers) pour leurs laissez assez de temps pour régler les problèmes de compatibilités.

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é et géré 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 paquet sans mainteneurs serons reconsidéré 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 empaqueteur, les apprentis n'ont aucun droit pour sur la commande maintdb
  • Vous pouvez le faire uniquement si le paquet est maintenu par personne (nobody) !'
  • Votre requête sera immédiatement traité 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 (par exemple n'étant pas un apprenti) vous pouvez directement questionner la base de donné des mainteneur avec :

 mgarepo maintdb get [packagename]

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

 :maint [packagename]

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 paquet 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, c.a.d 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 l'étiquette 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 sortie en version "pre-révision" avant une version "final". Elle inclue par exemple des étiquettes "alpha", "beta", "rc", "cvs", "git", "svn", etc et doit être ajouté à l'étiquette révision (release) et non pas à l'étiquette "version". Vous trouverez des détails en dessous.

Versions de pré-révision

Pour les paquet de développement ou de pré-révision l'étiquette 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 l'étiquette 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 acceptable :

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

rtmpdump peut aider a 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).

Étiquettes

  • L'étiquette de l'empaqueteur (Packager) ne doit pas être utilisé dans le fichier Spec. Les identités des empaqueteurs sont évident depuis les entrées du registre des changements (changelog). En évitant d'utiliser l'étiquette "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.
  • L'étiquette du vendeur (Vendor) ne pas non plus être utilisé. Il est automatiquement réglé par le système de construction (build system).
  • Ordinairement, l'étiquette PreReq doit être remplacé par entièrement par Requires. Pour plus d'information voir Maximum RPM fine grained dependencies chapter (en).
  • L'étiquette Source informe où trouver la source à l'amont du rpm. Dans la plus part des cas ça doit être le lien internet complet vers l'archive en amont (upstream tarball). La meilleur pratique veut l'utilisation de macros comme %version et %name pour permettre des mises à jours automatiques, mais ce n'est pas nécessaire.

L'étiquette résumé (Summary)

Cette étiquette 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ésultat de programme.

Il doit être adapté à toutes les situations standard et ne pas se préoccuper de contexte 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é dois ê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.

L'étiquette de groupe RPM (RPM Group)

L'étiquette 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.

L'étiquette buildRoot

L'étiquette 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.

L'étiquette PreReq

Les paquets ne doivent pas utiliser l'étiquette PreReq. À l'époque, pour résoudre le serpent qui se mort la queue dans la récursion de dépendances, cette étiquette é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.

L'étiquette 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 paquet 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éral on comptre 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 quel 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 suffit. De plus, dans quelques cas, d'ancienne 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 installés comme binaires ou des modules d'extension 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 paquet 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 puisse que le code à 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 étiquettes 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.

L'étiquette 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 étiquette 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 rends 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 paquet Si le paquet "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 en plus 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 fourniture virtueles indépendantes de l'architectures 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 porte aucune référence à l'architecture contrairement à devel(libsqlite3(64bit)) ou lib64sqlite3-devel(x86-64).

IMPORTANT : 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é dans le fichier spec comme BuildRequires.

Les étiquettes 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 a 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 bloque %ifarch. Les patches doivent être appliqué pour toutes les architectures et devraient contenir une configuration nécessaire et/ou un code de patch pour être effectif sur une architecture donnée.)

L'étiquette sources

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

L'étiquette patch (correctif, rustine)

Chaque problème doit être résolu par un correctif (patch) qui lui est propre. Ceci permet une maintenance facile des rustines, la source de la rustine doit être indiqué, spécialement si la rustine serait potentiellement mis à jour par la même source. Quand la rustine est ajoutée pour la première fois, la source doit être précisé dans le message du commit. Ça aide aussi pour obtenir un commentaire dans le fichier SPEC précisant sa provenance, ceci doit être l'URL complète de la source en amont si ce n'est pas une évidence, ainsi qu'une courte description de ce que la rustine fait avec des mots simples en anglais, si bien sûr cela de découle pas du nom de la rustine.

Les rustines doivent commencer avec le mot clef Patch0 dans le fichier SPEC, comme l'étiquette Source. Les rustines doivent être nommées 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, un 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 a appliquer avec un niveau de 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 leurs 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 a partir d'où le patch est appliqué
  • -b est le suffixe qui est ajouté au fichiers 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 meilleur compatibilité avec d'autres distributions.

L'étiquette %clean

L'étiquette %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 inclut 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 autre 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 l'étiquette 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 disponible en anglais, installez les décompressé dans %{buildroot}%{_mandir}/manX/ (où X est le numéro de section approprié). Ils seront automatiquement compressé avant d'être empaqueté, ainsi ils doivent être inscrit 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évu 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écessaire 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 fichier *.la sans avoir a modifier le programme. Dans la plus part 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 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 paquet 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épendant 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é à 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.

Librairies partagées

Dès que possible (et faisable), les paquets de Mageia contenant des librairies doivent être construite comme librairies 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 on en rencontre, veuillez enlever les appels à ldconfig et si c'était l'unique but de %post / %postun, alors supprimez entièrement ces sections vides.

Voir Libraries policy (en) pour plus de détails quant à la confection des paquets librairies.

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 pensez que faire ainsi brisera les choses. En d'autre 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 sensé 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 une 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'entré 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 essai 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 contenue du fichier .desktop.

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

Localiser les fichiers .desktop

Les valeurs de Name et de GenericName sont affiché comme légende à l'icône du bureau, ainsi elles doivent s'accorder avec la localisation conformément aux spécifications des entrées Desktop. La plus part du temps, seulement le code du langage (fr, de, etc) ou l'ensemble codes langage/pays sont nécessaire pour sélectionner la localisation 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écifie 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é 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é 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 paquet importé de Mandriva, les fichiers .desktop ont des entrés 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égories standard de Freedesktop. Vous les trouverez dans la spécification de Freedesktop.

La seule catégorie de Mandriva qui a sont équivalent encore sur Mageia est X-MandrivaLinux-CrossDesktop. Cette catégorie est prévu 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. For une références, veuillez vous référé au rapport de bug : 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 supprimerai aussi des information 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 au 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é Localisations, son abréviation est l10n, ou Internationalisation (i18n), le numéro dans les abréviations correspond au nombre de lettre omises), sont compilés dans des fichiers .mo. Cette section n'est pas à propos des pages Man.


(Si un paquet inclut des traduction, 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é 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 et voir comment sont ils nommé. S'ils sont nommé 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é à la macro %find_lang. Habituellement, il sera nommé %{name}.lang. Vous devriez alors utiliser ce fichier dans la liste %files pour ajoutez les fichiers régionaux détecté 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à utiliser 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 utiliser 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épertoire locaux, ce qui n'est pas permit.
  • La plus part des paquet 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 à sont 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 MUST.

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éparé 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 a propos des valeurs entières passé au scripts.

Les scriplets sont autorisé 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 quelque soit l'UID du constructeur.

L'usage de l'étiquette Epochs

L'étiquette Epoch dans RPM doit être utilisé qu'en dernier recourt, et doit être éviter 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épot tier.

Créer un paquet à partir de rien

Si vous voulez créer un paquet de zéro, voici le squelette d'un fichier SPEC où vous n'avez qu'a 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érifier l'exactitude du paquet et de sont 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 automone. 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, ...)
    • implémentent 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é 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ée 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 le registre des changements (changelog).

Registre des changements

Cette section décrit les consignes chez Mageia concernant le registre des changements des RPM nommé "changelogs". (Le registre des changements original des sources du logiciel en amont ne sont pas affecté par ces consignes.)

Veuillez considérer que "l'utilisateur final avec quelques compétences technique" devrait être capable de comprendre un registre de changement RPM. Les entrées du registre doit-être d'ordre anti-chronologique : les nouvelles entrées du registre des changements sont inscrite au dessus des anciennes entrées de la liste, la première entrée est la plus récente.

Gardez en esprit que le registre des changements de Magia 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é dans les registres des commits sur SVN, mais ils doivent tout de même être considéré 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 registre des changements 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 détaillé et plein de sens, mais aussi faites les aussi parlant que nécessaire afin que les prochains n'aient pas à lire les différences des changements pour analyser ce qui s'est effectivement passé.
  • Voici un mauvais exemple :
 - fixed foo

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

  • Voici un bonne 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 leurs nom complets 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é 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 à 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 registre des changements. Ne référez par les fichiers sources ou les correctifs par leurs numéro (ex S23 ou P12) puisse que les correctifs et les fichiers sources peuvent être renuméroté 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érentes doivent commencer avec le caractère 'moins' comme :
 - Bumped release
 - Added foo.patch

Ceci est optionnel pour les messages sur une seule ligne puisse que 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" (mga#4654).
- Symlink icon to pixmaps dir (mga#2108)
- Added gnome-ui-properties to control-center (mga#1960).

Les nouveaux paquets reliés à une nouvelle fonctionnalité sera 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 registre des changements 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écification

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 registre des changements.
  • Une chose qui ne doit pas être fait 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 étiquettes du préambule et des valeurs) la différence qui est produite par ça sera énorme.

Modification du code source

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

  • Regardez dans le registre des changements et sélectionnez les changements les plus importants pour la distribution (les changements pour d'autres systèmes d'exploitations ne sont pas important). Incluez ce qui a changé dans la nouvelle version, habituellement, le niveau de détaille du fichier NEWS; les fichiers des registres des changements sont généralement trop long. 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 registre des changements 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 registre des changements (à moins que ces correctifs contiennent quelque chose que vous trouvez en valoir la peine).

Empaquetage des librairies statiques

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

Les fichiers .a et .la ne devraient généralement pas être inclus nul part. Ils sont utiles uniquement lorsque quelqu'un veut lier statiquement un programme à une librairie (par exemple inclure la librairie dans le binaire du programme lui même, de cette manière la librairie 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 plus part 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 librairie 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 librairie donne au reste du monde et ne doit pas être entrepris à la légère.

Empaquetage des librairies statiques

  • En général, les empaqueteurs sont fortement décourager à envoyer des librairies statiques à moins qu'une irrésistible raison existe.
  • Nous voulons être en mesure de traquer quels paquets utilisent des librairies statiques (comme ça nous pouvons trouver quel paquets il est nécessaire de reconstruire au cas où un défaut de sécurité dans une librairie statique est réglé par exemple). Il y a deux cas où une librairie statique est empaqueté :
  1. Librairie statique et librairie partagé Dans ce cas, la librairie statique doit être placé dans un sous-paquet *-statis-devel. Séparer les librairies statiques des autres ficheirs de développement dans un *-devel nous permet de traquer cette usage en vérifiant quel 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 librairies statiques vers les librairies partagées.
  2. Librairies statiques uniquement. Quand un paquet fournit uniquement des librairies statique, vous pouvez placer tous les fichiers de librairies statiques dans un sous-paquet *-devel.
  • Si (et seulement si) un paquet à une librairie partagée qui requière une librairie statique pour être fonctionnelle, les librairies statiques peuvent être inclues dans un sous-paquet *-devel.

Lier statiquement les exécutables

  • Le liage statique est une exception spécial est devrait être décidé au cas par cas. L'empaqueteur doit fournir une justification du liage statique, pour obtenir une approbation.

Rendre un paquet obsolète

Lorsqu'un paquet n'est plus nécessaire 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-paquet 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'ajoutez un commentaire avec la raison de l'obsolescence, ou un lien vers la discussion de la mailing list 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)