[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ A ] [ suivant ]
La qualité de Debian est principalement due à la charte Debian qui
définit explicitement les obligations que tous les paquets doivent suivre.
Mais c'est également grâce à une histoire partagée d'expériences qui va au-delà
de la charte Debian, une accumulation d'années d'expérience pour la
construction des paquets ; des développeurs de grand talent ont créé de
bons outils qui vous aideront, vous, responsable Debian, à créer et maintenir
d'excellents paquets.
Ce chapitre fournit les meilleurs pratiques pour les développeurs Debian. Ce ne sont que des recommandations, non pas des obligations ou des règles. Ce sont seulement des astuces et conseils subjectifs et des liens collectés pour les développeurs Debian. Prenez et choisissez ce qui vous convient le mieux.
debian/rules
Les recommandations suivantes s'appliquent au fichier
debian/rules. Comme ce fichier contrôle le processus de
compilation et qu'il sélectionne les fichiers inclus dans le paquet
(directement ou indirectement), il s'agit habituellement du fichier sur lequel
les responsables passent le plus de temps.
La raison sous-jacente à l'utilisation des scripts d'aide dans le fichier
debian/rules est que cela permet aux responsables d'utiliser et de
partager une logique commune pour un grand nombre de paquets. Prenez, par
exemple, la question de l'installation des entrées de menu : vous avez
besoin de placer un fichier dans /usr/share/menu (ou
/usr/lib/menu pour des fichiers de menu binaires exécutables, si
nécessaire) et d'ajouter des commandes aux scripts de maintenance pour
enregistrer et désenregistrer ces entrées de menu. Comme il s'agit d'une chose
très commune, pourquoi chaque responsable devrait-il écrire sa propre version,
parfois avec des bogues ? Supposons également que le répertoire de menu
soit modifié, chaque paquet devrait être modifié.
Les scripts d'aide peuvent résoudre ces problèmes. En supposant que vous vous conformiez aux conventions attendues par le script d'aide, celui-ci prend soin de tous les détails. Les changements dans la charte peuvent alors être faits dans le script d'aide ; les paquets ont alors simplement besoin d'être reconstruits avec la nouvelle version du script et sans aucun changement supplémentaire.
L'Aperçu des outils du responsable Debian, Annexe
A contient plusieurs systèmes d'aide. Le plus courant et le meilleur (à
notre avis) système est debhelper. Les précédents systèmes d'aide
comme debmake étaient « monolithiques » : vous ne
pouviez pas choisir quelles parties intéressantes vous pouviez utiliser, mais
vous étiez obligé de choisir le système pour tout faire.
debhelper, à l'inverse, consiste en un certain nombre de petits
programmes dh_*. Par exemple, dh_installman installe
et compacte les pages de manuel, dh_installmenu installe les
fichiers de menu et ainsi de suite. Ainsi, il offre une flexibilité suffisante
pour pouvoir utiliser les scripts d'aide quand ils sont utiles, en complément
de commandes définies manuellement dans le fichier debian/rules.
Vous pouvez débuter avec debhelper en lisant
debhelper(1) et en regardant les exemples fournis avec le paquet.
dh_make du paquet dh-make (voir dh-make, Section A.3.3) peut
être utilisé pour convertir un paquet source « vierge » en une
version utilisant debhelper. Ce raccourci ne devrait cependant
pas vous faire croire que vous n'avez pas besoin de comprendre les scripts
individuels dh_*. Si vous comptez utiliser un système d'aide,
vous devez prendre le temps d'apprendre à utiliser ce système pour savoir ce
que vous pouvez en attendre ainsi que son comportement.
Plusieurs personnes pensent que des fichiers debian/rules vierges
sont préférables car vous n'avez pas à apprendre les détails internes d'un
quelconque système d'aide. La décision vous appartient complètement. Utilisez
ce qui vous convient. Plusieurs exemples de fichiers debian/rules
sont disponibles à http://arch.debian.org/arch/private/srivasta/.
Les gros paquets peuvent avoir plusieurs bogues que vous devez gérer. Si vous
corrigez sans faire attention les bogues dans les sources, vous ne pourrez pas
différencier facilement les nombreux correctifs que vous aurez appliqués. Cela
peut devenir très compliqué de mettre à jour le paquet avec une nouvelle
version amont qui intègre certains correctifs (mais pas tous). Vous ne pouvez
pas prendre l'ensemble des correctifs (par exemple, dans les fichiers
.diff.gz) et décider quels correctifs il vous faut enlever parce
que les bogues ont été corrigés en amont.
Malheureusement, le système de création des paquets tel qu'il est actuellement
ne fournit pas de moyen de séparer les correctifs en plusieurs fichiers.
Cependant, il existe des moyens de séparer les correctifs : les fichiers
correctifs sont livrés dans le fichier correctif Debian
(.diff.gz), habituellement dans le répertoire
debian/. La seule différence est qu'ils ne sont pas appliqués
immédiatement par dpkg-source, mais par la règle build du fichier
debian/rules. Inversement, ils sont annulés par la règle
clean.
dbs est l'une des approches les plus populaires pour cela. Il
fait ce qui est décrit ci-dessus et fournit la possibilité de créer de nouveaux
correctifs et de mettre à jour d'anciens correctifs. Veuillez vous reporter au
paquet dbs pour plus d'informations et au paquet
hello-dbs pour un exemple.
Dpatch fournit également ces fonctions, mais il est prévu pour
être encore plus facile d'utilisation. Veuillez voir le paquet
dpatch pour la documentation et des exemples (dans
/usr/share/doc/dpatch).
Un simple paquet source va souvent permettre de construire plusieurs paquets
binaires différents, que ce soit pour fournir plusieurs saveurs du même paquet
(par exemple, le paquet source vim) ou pour créer plusieurs petits
paquets au lieu d'un seul gros (afin, par exemple, que l'utilisateur puisse
n'installer que la partie nécessaire et ainsi économiser de l'espace disque).
Le second cas peut facilement être géré dans le fichier
debian/rules. Vous avez simplement besoin de déplacer les
fichiers appropriés du répertoire de construction dans les arborescence
temporaires du paquet. Vous pouvez le faire en utilisant install
ou dh_install du paquet debhelper. Assurez-vous de
vérifier les différentes permutations de paquets, en garantissant que vous avez
bien défini les dépendances entre les paquets dans le fichier
debian/control.
Le premier cas est un peu plus difficile car il implique de multiples
recompilations du même logiciel, mais avec différentes options de
configuration. Le paquet source vim est un exemple de la façon de
gérer cela avec un fichier rules écrit à la main.
debian/control
Les pratiques suivantes sont relatives au fichier debian/control.
Elles viennent en complément des règles
pour les descriptions des paquets.
La description du paquet, telle qu'elle est définie par le champ correspondant
dans le fichier control, contient à la fois le résumé du paquet et
la description longue pour le paquet. Les règles
générales pour les descriptions des paquets, Section 6.2.1 décrit des
lignes générales pour les deux parties de la description. Ensuite, Le résumé du paquet ou description courte, Section
6.2.2 fournit des principes spécifiques pour le résumé et La description longue, Section 6.2.3 contient des
principes spécifiques pour la description longue.
La description du paquet devrait être écrite pour l'utilisateur moyen, l'utilisateur qui va utiliser et bénéficier du paquet. Par exemple, les paquets de développement sont pour les développeurs et leur description peut utiliser un langage technique. Pour les applications à but plus général comme un éditeur, la description devrait être écrite pour un non-spécialiste.
Notre critique des descriptions des paquets nous amène à conclure que la plupart des descriptions des paquets sont techniques, c'est-à-dire, qu'elles ne sont pas écrites pour être comprises par les non-spécialistes. À moins que votre paquet ne soit que pour les techniciens, c'est un problème.
Comment écrire pour les non-spécialistes ? Évitez le jargon. Évitez de vous référer à d'autres applications et cadres de travail avec lesquels l'utilisateur n'est pas forcément familier — « GNOME » ou « KDE » sont corrects car les utilisateurs sont probablement familiers avec ces termes, mais « GTK+ » ne l'est probablement pas. Ne supposez aucune connaissance. Si vous devez utiliser des termes techniques, introduisez-les.
Soyez objectif. Les descriptions de paquet ne sont pas un endroit pour promouvoir votre paquet, quel que soit l'amour que vous lui portez. Rappelez-vous que le lecteur n'a pas forcément les mêmes priorités que vous.
Des références aux noms de tout autre paquet de logiciels, noms de protocoles, standards ou spécifications devraient utiliser leurs formes canoniques si elles existent. Par exemple, utilisez « X Window System », « X11 » ou « X » et non « X Windows », « X-Windows » ou « X Window ». Utilisez « GTK+ » et non « GTK » ou « gtk ». Utilisez « GNOME » et non « Gnome ». Utilisez « PostScript » et non « Postscript » ou « postscript ».
Si vous avez des problèmes pour écrire votre description, vous pouvez l'envoyer
à [email protected]
et demander un retour d'informations.
La ligne de résumé (la description courte) devrait être concise. Elle ne doit pas répéter le nom du paquet (c'est une règle).
C'est une bonne idée de penser au résumé comme à une clause apposée et non une phrase complète. Une clause apposée est définie dans WordNet comme une relation grammaticale entre un mot et une phrase pronominale qui la suit, par exemple « Rudolph, le renne au nez rouge ». La clause apposée ici est « le renne au nez rouge ». Comme le résumé est une clause et non une phrase complète, nous recommandons de ne pas la commencer par une majuscule et de ne pas la finir par un point. Il ne doit pas non plus commencer avec un article, défini (« le ») ou indéfini (« un »).
Cela peut vous aider d'imaginer le résumé combiné avec le nom du paquet de la façon suivante :
nom-paquet est un résumé.
Sinon, il peut être plus compréhensible de le voir comme
nom-paquet est résumé.
ou, si le nom du paquet est lui-même un pluriel (comme « developer-tools »)
nom-paquet sont résumé.
Cette façon de former une phrase à partir du nom du paquet et du résumé devrait être considérée comme une heuristique et non comme une règle stricte. Il y a certains cas où cela n'a aucun sens de former une phrase.
La description longue du paquet est la première information dont dispose l'utilisateur avant d'installer un paquet. Aussi, elle devrait fournir toutes les informations nécessaires pour le laisser décider de l'installation du paquet. Vous pouvez supposer que l'utilisateur a déjà lu le résumé du paquet.
La description longue devrait toujours être constituée de phrases complètes.
Le premier paragraphe de la description longue devrait répondre aux questions suivantes : qu'est-ce que fait le paquet ? Quelle tâche aide-t-il l'utilisateur à accomplir ? Il est important de décrire ceci d'une manière non technique, à moins que le paquet ne s'adresse qu'à un auditoire de techniciens.
Les paragraphes suivants devraient répondre aux questions suivantes : Pourquoi, en tant qu'utilisateur, ai-je besoin de ce paquet ? Quelles sont les autres fonctionnalités dont dispose le paquet ? Quelles sont les fonctionnalités marquantes et les déficiences de ce paquet comparé à d'autres paquets (par exemple, « si vous avez besoin de X, utilisez Y à la place ») ? Est-ce que le paquet est lié à d'autres paquets d'une certaine façon qui n'est pas gérée par le gestionnaire de paquet (par exemple, « il s'agit d'un client pour le serveur foo ») ?
Soyez attentif à éviter les fautes d'orthographe et de grammaire. N'oubliez
pas votre vérificateur orthographique. Les deux programmes ispell
et aspell possèdent des modes spéciaux pour vérifier les fichiers
debian/control :
ispell -d american -g debian/control
aspell -d en -D -c debian/control
Les utilisateurs s'attendent habituellement à ce que les réponses aux questions suivantes soient présentes dans la description du paquet :
Qu'est-ce que fait le paquet ? Si c'est un ajout d'un autre paquet, la description courte du paquet dont c'est un ajout devrait le spécifier.
Pourquoi est-ce qu'il voudrait installer ce paquet ? Ceci est lié à ce qui est ci-dessus, mais pas tout à fait (c'est un client de messagerie ; il est cool, rapide, s'interface avec PGP, LDAP et IMAP, a les fonctionnalités X, Y et Z).
Si ce paquet ne devrait pas être installé directement, mais être tiré par un autre paquet, cela devrait être mentionné.
Si le paquet est expérimental, ou s'il y a d'autres raisons pour lesquelles il ne devrait pas être utilisé, si un autre paquet devrait être utilisé à la place, cela devrait également être présent.
En quoi le paquet est différent des paquets concurrents ? Est-ce que c'est une meilleure implémentation ? A-t-il plus de fonctionnalités, des fonctionnalités différentes ? Pourquoi devrait-il choisir ce paquet ?
Nous vous recommandons d'ajouter l'adresse de la page d'accueil du paquet à la
description du paquet dans le fichier debian/control. Cette
information devrait être ajoutée à la fin de la description en utilisant le
format suivant :
.
Homepage: http://some-project.some-place.org/
Veuillez noter les espaces au début de la ligne, ils servent à séparer les
lignes correctement. Pour voir un exemple de ce que cela affiche, veuillez
vous reporter à http://packages.debian.org/unstable/web/wml.
Ne mettez rien s'il n'existe pas de page pour le logiciel.
Veuillez noter que nous espérons que ce champ sera remplacé par un vrai champ
de debian/control qui serait compris par dpkg et
packages.debian.org. Si vous ne voulez pas vous embêter à
déplacer la page d'accueil depuis la description vers ce nouveau champ, vous
devriez probablement attendre qu'il soit disponible. Veuillez vous assurer que
cette ligne correspond à l'expression rationnelle /^ Homepage: [^
]*$/ car cela permet à packages.debian.org de l'analyser
correctement.
debian/changelog
Les pratiques suivantes viennent en complément de la directive
sur les fichiers changelog.
L'entrée de changelog pour une révision de paquet documente les changements dans cette révision et seulement ceux-ci. Concentrez-vous sur la description des changements significatifs et visibles de l'utilisateur qui ont été effectués depuis la dernière version.
Ciblez ce qui a été changé — qui, comment et quand cela a été fait est généralement de moindre importance. Ceci dit, rappelez-vous de nommer poliment les personnes qui ont fourni une aide notable pour réaliser le paquet (par exemple, ceux qui ont envoyé des correctifs).
Vous n'avez pas besoin de détailler les changements triviaux et évidents. Vous
pouvez également regrouper plusieurs de ces changements dans une seule entrée.
D'un autre côté, ne soyez pas trop concis si vous avez entrepris un changement
majeur. Soyez tout spécialement clair s'il y a des changements qui modifient
le comportement du programme. Pour plus d'explications, utilisez le fichier
README.Debian.
Utilisez un langage anglais commun pour que la majorité des lecteur puissent le comprendre. Évitez les abréviations, le parler technique et le jargon quand vous expliquez des changements fermant un bogue, spécialement pour les rapports de bogue créés par des utilisateurs qui ne vous paraissent pas particulièrement à l'aise techniquement. Vous devez être poli et ne pas jurer.
Il est parfois désirable de préfixer les entrées de changelog avec le nom des fichiers qui ont été modifiés. Cependant, il n'est pas besoin de lister explicitement tous les fichiers modifiés, particulièrement si la modification est petite ou répétitive. Vous pouvez utiliser les caractères génériques.
Quand vous faites référence aux bogues, ne supposez rien a priori. Dites ce qu'était le problème, comment il a été résolu et ajoutez la chaîne de caractères « closes: #nnnnn ». Veuillez voir Quand les rapports de bogue sont-ils fermés par une mise à jour ?, Section 5.8.4 pour plus d'informations.
Les entrées de changelog ne devraient pas documenter des problèmes génériques d'empaquetage (« Hé, si vous cherchez foo.conf, il est dans /etc/blah/. ») car les administrateurs et utilisateurs sont supposés être au moins vaguement rompus à la façon dont les choses sont arrangées sur un système Debian. Mentionnez cependant tout changement d'emplacement d'un fichier de configuration.
Les seuls bogues fermés par une entrée de changelog devraient être ceux qui sont vraiment corrigés dans la même révision du paquet. Fermer des bogues non liés par le fichier changelog est considéré comme une très mauvaise pratique. Veuillez voir Quand les rapports de bogue sont-ils fermés par une mise à jour ?, Section 5.8.4.
Les entrées de changelog ne devraient pas être le lieu de discussions avec les émetteurs de bogues (« Je ne vois pas de segfaults lors du lancement de foo avec l'option bar ; envoyez-moi plus d'informations. »), ni celui de phrases génériques sur la vie, l'univers et tout le reste (« Désolé, cet envoi m'a pris du temps, mais j'avais attrapé la grippe ») ou celui de demandes d'aide (« La liste des bogues sur ce paquet est énorme, donnez-moi un coup de main »). Ceci ne sera généralement pas remarqué par les personnes ciblées, mais peut ennuyer les personnes qui désirent lire des informations sur les changements réels du paquet. Veuillez vous reporter à Répondre à des rapports de bogue, Section 5.8.2 pour plus d'informations sur la façon d'utiliser le système de suivi des bogues.
C'est une vieille tradition de valider les bogues fixés par une mise à jour indépendante dans la première entrée du changelog de l'envoi du vrai responsable. Comme nous avons maintenant le suivi des versions, il est suffisant de garder les entrées de changelog des mises à jour indépendantes et de simplement mentionner ce fait dans votre propre entrée de changelog.
Les exemples suivants montrent des erreurs communes ou des exemples de mauvais style dans les entrées de changelog[28].
* Corrige tous les bogues restants.
Ceci n'indique visiblement rien d'utile au lecteur.
* Correctif de Jane Random appliqué.
Sur quoi portait le correctif ?
* Révision de cible d'installation la nuit dernière.
Qu'a accompli la révision ? Est-ce que la mention de la nuit dernière est supposée nous rappeler que nous ne devons pas faire confiance à ce code ?
* Corrige MRD vsync av. anciens CRTs.
Trop d'acronymes et il n'est pas très clair de ce qu'était vraiment cette... euh... merde (oups, un mot interdit !) ou comment cela a été corrigé.
* Ceci n'est pas un bogue. Closes: #nnnnnn.
Premièrement, il n'y a absolument pas besoin d'envoyer un paquet pour communiquer cette information ; à la place, utilisez le système de suivi des bogues. Deuxièmement, il n'y a aucune explication concernant la raison pour laquelle le rapport n'était pas un bogue.
* A été fixé il y a longtemps, mais j'ai oublié de le fermer. Closes: #54321.
Si, pour toute raison, vous n'aviez pas indiqué le numéro du bogue dans une précédente entrée de changelog, ceci n'est pas un problème, fermez simplement le bogue normalement dans le BTS. Il n'y a pas besoin de modifier le fichier changelog, en supposant que la description de la correction est déjà intégrée (ceci s'applique aux correctifs par les auteurs/responsables amont également, vous n'avez pas à suivre les bogues qui ont été corrigés il y a longtemps dans votre changelog).
* Closes: #12345, #12346, #15432.
Où est la description ?! Si vous n'arrivez pas à trouver un message descriptif, commencez par insérer le titre de chacun des différents bogues.
Les nouvelles importantes à propos des changements dans un paquet peuvent également être placées dans les fichiers NEWS.Debian. Ces nouvelles seront affichées par des outils comme apt-listchanges, avant le reste des changelogs. Ceci est le moyen préféré pour informer les utilisateurs des changements significatifs dans un paquet. Il est préférable d'utiliser ce fichier plutôt que d'utiliser des notes debconf car c'est moins ennuyeux et l'utilisateur peut y revenir et se référer au fichier NEWS.Debian après l'installation. Et c'est mieux que de lister les changements principaux dans README.Debian car l'utilisateur peut facilement rater de telles notes.
Le format du fichier est le même que pour un fichier de changelog Debian, mais il n'utilise pas d'astérisques et décrit chaque élément de nouvelle dans un paragraphe complet si nécessaire plutôt que les résumés concis qui iraient dans un changelog. C'est une bonne idée de passer votre fichier par dpkg-parsechangelog pour vérifier son formatage car il n'est pas vérifié automatiquement pendant la construction comme le changelog. Voici un exemple d'un vrai fichier NEWS.Debian :
cron (3.0pl1-74) unstable; urgency=low
The checksecurity script is no longer included with the cron package:
it now has its own package, "checksecurity". If you liked the
functionality provided with that script, please install the new
package.
-- Steve Greenland <[email protected]> Sat, 6 Sep 2003 17:15:03 -0500
Le fichier NEWS.Debian est installé comme /usr/share/doc/<package>/NEWS.Debian.gz. Il est compressé et a toujours ce nom même dans les paquets natifs Debian. Si vous utilisez debhelper, dh_installchangelogs installera les fichiers debian/NEWS pour vous.
À la différence des fichiers changelog, vous n'avez pas besoin de mettre à jour les fichiers NEWS.Debian à chaque nouvelle version. Ne les mettez à jour que si vous avez quelque chose de particulièrement important que l'utilisateur a besoin de savoir. Si vous n'avez pas de nouvelles du tout, il n'est pas nécessaire de fournir de fichier NEWS.Debian dans votre paquet. Pas de nouvelles, bonne nouvelle !
Les scripts de maintenance incluent les fichiers debian/postinst,
debian/preinst, debian/prerm et
debian/postrm. Ces scripts prennent en charge la configuration
d'installation ou de désinstallation des paquets, ce qui n'est pas simplement
créer ou supprimer des fichiers et des répertoires. Les instructions suivantes
complètent la charte
Debian.
Les scripts de maintenance doivent être idempotents. Cela veut dire que vous devez vous assurer que rien de grave ne se produit si un script est appelé deux fois là où il ne devrait habituellement être appelé qu'une fois.
Les entrée et sortie standard peuvent être redirigées (par exemple, dans des tubes[29]) pour des besoins d'enregistrement d'activité, donc vous ne devez pas supposer que ce sont des tty.
Tous les affichages et les configurations interactives devraient être
minimisées. Quand cela est nécessaire, vous devriez utiliser le paquet
debconf pour l'interface. Rappelez-vous que, dans tous les cas,
l'affichage ne doit se faire que dans l'étape de configuration,
configure du script de post-installation, postinst.
Gardez les scripts de maintenance aussi simples que possible. Nous vous
suggérons d'utiliser des scripts shell POSIX purs. Rappelez-vous, que si vous
avez besoin d'une fonctionnalité de Bash, le script de maintenance doit
préciser bash dans sa première ligne. Un shell POSIX ou Bash sont préférés à
Perl car ils permettent à debhelper d'ajouter facilement des
parties aux scripts.
Si vous modifiez les scripts de maintenance, assurez-vous de tester la suppression du paquet, la double installation et la purge complète. Assurez-vous qu'il ne reste rien d'un paquet purgé, c'est-à-dire, que la purge doit enlever tout fichier créé, directement ou indirectement, par les scripts de maintenance.
Si vous avez besoin de vérifier l'existence d'une commande, vous devriez utiliser quelque chose comme :
if [ -x /usr/sbin/install-docs ]; then ...
Si vous ne désirez pas mettre en dur le chemin d'une commande dans le script de maintenance, la fonction de shell suivante conforme à POSIX peut vous aider :
pathfind() {
OLDIFS="$IFS"
IFS=:
for p in $PATH; do
if [ -x "$p/$*" ]; then
IFS="$OLDIFS"
return 0
fi
done
IFS="$OLDIFS"
return 1
}
Vous pouvez utiliser cette fonction pour rechercher le $PATH pour
un nom de commande passé en paramètre. Il renvoie vrai (zéro) si la commande a
été trouvée et faux sinon. Il s'agit réellement de la façon la plus portable
de faire car command -v, type et which
ne sont pas POSIX.
Bien que which soit une alternative acceptable car il est présent
dans le paquet classé required debianutils, il n'est pas
présent dans la partition racine. Autrement dit, il est placé dans
/usr/bin au lieu de /bin, il n'est donc pas possible
de l'utiliser dans les scripts qui sont exécutés avant que la partition
/usr soit montée. Cependant, la plupart des scripts n'auront pas
ce problème.
debconf
Debconf est un système de gestion de configuration qui peut être
utilisé par les divers scripts de maintenance (principalement en
post-installation dans le fichier postinst) pour demander à
l'utilisateur des informations concernant la configuration du paquet. Il faut
maintenant éviter les interactions directes avec l'utilisateur et préférer les
interactions utilisant debconf. Ceci permettra à l'avenir des
installations non interactives.
Debconf est un bon outil, mais il est souvent mal utilisé. Plusieurs erreurs
communes sont référencées dans la page de manuel debconf-devel(7).
Vous devriez vraiment lire cette page si vous décidez d'utiliser debconf. Nous
documentons également plusieurs des meilleures pratiques ici.
Ces lignes directives incluent plusieurs recommandations de style d'écriture et de typographie, des considérations générales à propos de l'utilisation de debconf ainsi que des recommandations plus spécifiques pour certaines parties de la distribution (par exemple, le système d'installation).
Depuis que debconf est apparu dans Debian, il a été largement abusé et plusieurs critiques reçues par la distribution Debian proviennent d'utilisation abusive de debconf avec la nécessité de répondre à un grand nombre de questions avant d'avoir n'importe quel petit logiciel d'installé.
Garder les notes d'utilisation à leur place : le fichier NEWS.Debian ou le fichier README.Debian. N'utilisez des notes que pour des notes importantes qui peuvent directement concerner l'utilisation du paquet. Rappelez-vous que les notes bloqueront toujours l'installation avant leur confirmation ou qu'elles embêtent l'utilisateur par un courriel.
Choisissez avec soin les priorités des questions dans les scripts de
responsable. Reportez-vous à debconf-devel(7) pour plus de
détails sur les priorités. La plupart des questions devraient utiliser un
priorité moyenne ou basse.
La plupart des responsables de paquets Debian n'ont pas l'anglais comme langue maternelle. Écrire des modèles correctement rédigés peut donc ne pas être facile pour eux.
Veuillez utiliser (et abuser de) la liste de discussions [email protected].
Faites relire vos questionnaires.
Des questionnaires écrits incorrectement donnent une pauvre image de votre paquet, de votre travail... ou même de Debian elle-même.
Évitez le jargon technique autant que possible. Si certains termes vous semblent courants, ils peuvent être impossibles à expliquer à d'autres personnes. Si vous ne pouvez pas les éviter, essayez de les expliquer (en utilisant la description étendue). Quand vous faites cela, essayez d'équilibrer la verbosité et la simplicité.
Les questionnaires debconf peuvent être traduits. Debconf, avec son
paquet-frêre po-debconf, offre un cadre de travail simple pour
obtenir des questionnaires traduits par les équipes de traduction ou même par
des individus isolés.
Veuillez utiliser les questionnaires basés sur gettext. Installez
po-debconf sur votre système de développement et lisez sa
documentation (« man po-debconf » est un bon début).
Évitez de changer vos questionnaires trop souvent. Modifier le texte des questionnaires entraîne plus de travail pour les traducteurs dont les traductions seront rendues « floues » (« fuzzy »). Si vous prévoyez des modifications dans vos questionnaires d'origine, veuillez contacter les traducteurs. La plupart des traducteurs actifs sont très réactifs et obtenir leur travail inclus avec vos questionnaires modifiés vous économisera des envois supplémentaires. Si vous utilisez des modèles basés sur gettext, le nom et l'adresse électronique du traducteur sont mentionnés dans les en-têtes des fichiers PO.
L'utilisation de podebconf-report-po du paquet
po-debconf est hautement recommandée pour avertir les traducteurs
qui ont des traductions incomplètes et pour leur demander des mises à jour.
En cas de doutes, vous pouvez également contacter l'équipe de traduction pour
une langue donnée ([email protected]) ou la liste de
discussions [email protected].
Les appels à traductions postés sur [email protected]
avec le fichier debian/po/templates.pot attaché ou référencé dans
une URL sont encouragés. Assurez-vous de mentionner dans ces appels pour de
nouvelles traductions quelles sont les langues pour lesquelles vous avez déjà
des traductions existantes, pour éviter toute duplication de travail.
Quand le texte d'un questionnaire debconf est corrigé et que vous êtes certain que les changements n'ont aucun effet sur les traductions, soyez courtois avec les traducteurs et dé-fuzzy-fiez leurs traductions.
Si vous ne le faites pas, le questionnaire entier ne sera pas traduit jusqu'à ce qu'un traducteur vous envoie une mise à jour.
Pour dé-fuzzy-fier les traductions, vous pouvez procéder ainsi :
enlevez tous les fichiers PO incomplets. Vous pouvez vérifier si les fichiers
sont complets en utilisant (il faut que le paquet gettext soit
installé) :
for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
--statistics $i; done
déplacez tous les fichiers ayant des chaînes floues (« fuzzy ») dans un emplacement temporaire. Les fichiers n'ayant aucune chaîne floue (seulement des chaînes traduites et non traduites) seront conservées où ils sont placés,
maintenant et seulement maintenant, corrigez les typos dans le questionnaire et vérifiez que les traductions ne sont pas impactées (les typos, les fautes d'orthographe et parfois les corrections de typographie sont généralement acceptables),
exécutez debconf-updatepo. Cela va fuzzifier toutes les chaînes
que vous avez modifiées dans les traductions. Vous pouvez constater cela en
exécutant à nouveau la commande ci-dessus,
utilisez la commande suivante :
for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done
déplacez dans debian/po les fichiers qui avaient des chaînes floues dans la première étape,
exécutez à nouveau debconf-updatepo.
Le texte des modèles ne doit pas faire référence aux composants appartenant à l'une des interfaces debconf. Des phrases comme « If you answer Yes... » n'a aucun sens pour les utilisateurs d'interfaces graphiques qui utilisent des cases à cocher pour les questions booléennes.
Les modèles de chaînes de caractères devraient éviter de mentionner les valeurs par défaut dans leur description. Tout d'abord, parce que cela est redondant avec les valeurs lues par les utilisateurs. Ensuite, parce ces valeurs par défaut peuvent être différentes selon les choix du responsable (par exemple, quand la base de données debconf a été préremplie).
Plus généralement, essayez d'éviter de vous référer à toute action de l'utilisation. Donnez simplement des faits.
Vous devriez éviter d'utiliser la première personne (« I will do this... » ou « We recommend... »). L'ordinateur n'est pas une personne et les questionnaires debconf ne parlent pas pour les développeurs Debian. Vous devriez utiliser une construction neutre et souvent une forme passive. Pour ceux d'entre vous qui écrivent déjà des publications scientifiques, écrivez simplement vos questionnaires comme vous écririez un papier scientifique.
Le monde est fait d'hommes et de femmes. Veuillez utiliser des constructions neutres dans le genre dans votre texte. Ce n'est pas du politiquement correct, c'est simplement montrer du respect pour toute l'humanité.
Cette partie donne plusieurs informations qui sont principalement extraites de
la page de manuel debconf-devel(7).
Résulte en un champ d'entrée libre dans lequel l'utilisateur peut écrire toute chaîne.
Demande un mot de passe à l'utilisateur. Veuillez utiliser ce champ avec précaution ; soyez conscient que le mot de passe que l'utilisateur entre sera écrit dans la base de données debconf. Vous devriez probablement enlever cette valeur de la base de données dès que possible.
Un choix vrai/faux. Rappelez-vous : vrai/faux, pas oui/non...
Un choix parmi un certain nombre de valeurs. Les choix doivent être spécifiés dans un champ nommé « Choices ». Séparez les valeurs possibles par des virgules et des espaces ainsi : Choices: yes, no, maybe
Comme le type de données select, excepté que l'utilisateur peut choisir un nombre quelconque d'éléments dans la liste de choix (ou aucun d'entre eux).
Plutôt que d'être une question en tant que telle, ce type de donnée indiqué une note qui peut être affichée à l'utilisateur. Il ne devrait être utilisé que pour des données importantes que l'utilisateur doit réellement voir, car debconf fera tout ce qu'il peut pour s'assurer que l'utilisateur le voit ; il stoppera l'installation en attendant que l'utilisateur appuie sur une touche ou il leur enverra même la note par courrier dans certains cas.
Ce type est maintenant considéré comme obsolète : ne l'utilisez pas.
CE TYPE DE MODÈLE N'EST PAS ENCORE GÉRÉ PAR DEBCONF.
Il a été ajouté à cdebconf, la version C de debconf, utilisé en premier dans l'installateur Debian.
Veuillez ne pas l'utiliser à moins que debconf ne le prenne en charge.
Ce type est conçu pour gérer des messages d'erreur. Il est presque semblable au type « note ». Des interfaces peuvent le présenter différemment (par exemple, l'interface dialog de cdebconf affiche un écran rouge au lieu de l'écran bleu habituel).
Les descriptions des modèles sont composées de deux parties : une courte et une étendue. La description courte est dans la ligne « Description: » du questionnaire.
La description courte devrait être gardée courte (50 caractères ou moins) pour qu'elle puisse être ajustée par la plupart des interfaces debconf. La garder courte aide également les traducteurs, car les traductions ont tendance à être plus longues que l'original.
La description courte devrait se suffire à elle-même. Certaines interfaces n'affichent pas la description longue par défaut ou seulement si l'utilisateur la demande explicitement ou même ne l'affichent pas du tout. Évitez des choses comme « What do you want to do ? ».
Il n'est pas nécessaire que la description courte soit une phrase complète. Cela fait partie de la recommandation « gardez-la courte et efficace ».
La description étendue ne devrait pas répéter la description courte mot pour mot. Si vous ne trouvez pas de description longue, commencez par à y réfléchir plus. Envoyez un message sur debian-devel. Demandez de l'aide. Suivez un cours d'écriture ! La description étendue est importante. Si, après tout cela, vous ne trouvez toujours rien, laissez-la vide.
La description étendue devrait utiliser des phrases complètes. Des paragraphes devraient être gardés court pour améliorer la lisibilité. Ne mélangez pas deux idées dans le même paragraphe, mais utilisez plutôt un autre paragraphe.
Ne soyez pas trop verbeux. Les utilisateurs ont tendance à ignorer les écrans trop longs. Par expérience, 20 lignes est la limite à éviter de dépasser car cela veut dire sinon que, dans l'interface dialogue classique, les utilisateurs devront faire défiler le texte et un grand nombre de personnes ne le font simplement pas.
Pour des règles spécifiques selon le type de questionnaire (chaîne de caractères, booléen, etc.), veuillez lire ci-dessous.
Ce champ devrait utilisé pour des types Select et Multiselect. Il contient les choix possibles qui seront présentés aux utilisateurs. Ces choix devraient être séparés par des virgules.
Ce champ est facultatif. Il contient la réponse par défaut pour les modèles chaîne de caractères, sélection et multi-sélection. Pour des questionnaires multi-sélection, il peut contenir une liste de choix séparés par des virgules.
Aucune indication spécifique excepté : utilisez le type approprié en vous référant à la section précédente.
Voici ci-dessous des instructions spécifiques pour écrire correctement la description (courte et étendue) selon le type de questionnaire.
La description courte est une invite et non un titre. Évitez des invites de style question (« IP Address? ») en faveur d'invites « ouvertes »à (« IP address: »). L'utilisation des deux-points est recommandée.
La description étendue est un complément à la description courte. Dans la partie étendue, expliquez ce qui est demandé, plutôt que de poser la même question à nouveau en utilisant des mots plus longs. Utilisez des phrases complètes. Un style d'écriture trop concis est fortement découragé.
La description courte devrait être rédigée sous la forme d'une question qui devrait être gardée courte et devrait généralement se terminer par un point d'interrogation. Un style d'écriture concis est permis et même encouragé si la question est plutôt longue (rappelez-vous que les traductions sont souvent plus longue que les versions d'origine)
La description étendue ne devrait pas inclure de question.
À nouveau, veuillez éviter de vous référer à des composants d'interface spécifiques. Une erreur courante pour de telles questionnaires est les constructions du type « if you answer Yes ».
La description courte est une invite et non un titre. N'utilisez pas des constructions inutiles du type « Please choose... ». Les utilisateurs sont assez intelligents pour réaliser qu'ils doivent choisir quelque chose...:)
La description étendue devra compléter la description courte. Elle peut se référer aux choix disponibles. Elle peut également mentionner que l'utilisateur peut choisir plus d'un des choix disponibles si le questionnaire est du type sélection multiple (bien que l'interface rende souvent cela clair).
La description courte devrait être considéré comme un *titre*.
La description étendue est ce qui sera affiché comme une description plus détaillée de la note. Faites des phrases, n'utilisez pas un style d'écriture trop concis.
N'abusez pas de debconf. Les notes sont le moyen le plus courant d'abus de debconf. Comme il est écrit dans la page de manuel de debconf-devel : il est préférable de ne les utiliser que pour des avertissements à propos de problèmes très sérieux. Les fichiers NEWS.Debian ou README.Debian sont les endroits appropriés pour un grand nombre de notes. Si, en lisant ceci, vous envisagez de convertir vos modèles de type note en entrées dans NEWS/Debian ou README.Debian, veuillez considérer de conserver les traductions existantes pour une utilisation future.
S'il est probable que les choix changent souvent, veuillez considérer l'utilisation de l'astuce « __Choices ». Cela séparera chaque choix individuel en une chaîne de caractères seule, ce qui aidera considérablement les traducteurs à faire leur travail.
S'il est probable que la valeur par défaut d'un modèle « select » change selon la langue de l'utilisateur (par exemple, s'il s'agit d'un choix de langue), veuillez utiliser l'astuce « _DefaultChoice ».
Ce champ spécial permet aux traducteurs de positionner le choix le plus approprié selon leur propre langue. Cela deviendra le choix par défaut quand leur langue sera sélectionnée alors votre choix par défaut sera utilisé pour l'anglais.
Un exemple tiré des modèles du paquet geneweb :
Template: geneweb/lang
Type: select
__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
# This is the default choice. Translators may put their own language here
# instead of the default.
# WARNING : you MUST use the ENGLISH FORM of your language
# For instance, the french translator will need to put "French (fr)" here.
_DefaultChoice: English (en)[ translators, please see comment in PO files]
_Description: Geneweb default language:
Notez l'utilisation de crochets qui permettent des commentaires internes dans les champs debconf. Notez également l'utilisation de commentaires qui apparaîtront dans les fichiers sur lesquels travailleront les traducteurs.
Les commentaires sont nécessaires car l'astuce DefaultChoice est un peu déroutante : les traducteurs peuvent y placer leur propre choix.
N'utilisez PAS de champ par défaut vide. Si vous ne voulez pas utiliser de valeurs par défaut, n'utilisez simplement pas du tout Default.
Si vous utilisez po-debconf (et vous devriez le faire, voir 2.2), veuillez considérer de rendre ce champ traduisible, si vous pensez qu'il peut être traduit.
Si la valeur par défaut peut varier selon la langue ou le pays (par exemple, la
valeur par défaut pour un choix de langue), veuillez considérer l'utilisation
du type spécial « _DefaultChoice » documenté dans
po-debconf(7)).
Comme les porteurs, les traducteurs ont une tâche difficile. Ils travaillent sur un grand nombre de paquets et doivent donc collaborer avec plusieurs responsables différents. De plus, la plupart du temps, l'anglais n'est pas leur langue maternelle, il se peut que vous deviez être particulièrement patient avec eux.
Le but de debconf était de faciliter la configuration des paquets
aux responsables et aux utilisateurs. À l'origine, les traductions des
questionnaires debconf étaient gérées avec debconf-mergetemplate.
Cependant, cette technique est maintenant déconseillée ; la meilleure
façon pour l'internationalisation de debconf est d'utiliser le
paquet po-debconf. Cette méthode est plus facile pour le
responsable et pour les traducteurs ; des scripts de transition sont
fournis.
Lors de l'utilisation de po-debconf, la traduction est stockée
dans des fichiers po (à l'instar des techniques de traduction de
gettext). Des fichiers modèles contiennent les messages d'origine
et indiquent quels sont les champs traduisibles. Quand vous modifiez l'état
d'un champ traduisible en appelant debconf-updatepo, la traduction
est marquée comme ayant besoin de l'attention des traducteurs. Puis, lors de
la construction du paquet, le programme dh_installdebconf prendra
soin de toute la magie nécessaire à l'ajout du modèle avec les traductions à
jour dans les paquets binaires. Veuillez vous reporter à la page de manuel
po-debconf(7) pour les détails.
La traduction de la documentation est cruciale pour les utilisateurs, mais elle représente un important travail. Il n'existe aucun moyen d'éliminer ce travail, mais vous pouvez faciliter les choses pour les traducteurs.
Si vous êtes responsable d'une documentation quelle que soit sa taille, il est
plus facile pour les traducteurs d'avoir accès à un système de contrôle de
source. Ceci permet aux traducteurs de voir les différences entre deux
versions de la documentation, pour, par exemple, qu'ils puissent voir ce qui a
besoin d'être retraduit. Il est recommandé que le document traduit inclue une
note à propos de la révision de contrôle du source sur laquelle la traduction
est basée. Un système intéressant est fourni par doc-check
dans le paquet boot-floppies qui donne un aperçu de l'état de la
traduction pour une langue donnée, en utilisant les commentaires structurés
pour une révision donnée du fichier à traduire et, pour un fichier traduit, la
révision du fichier d'origine sur laquelle la traduction est basée. Vous
pouvez vouloir adapter et fournir ceci dans votre référentiel CVS.
Si vous maintenez de la documentation au format XML ou SGML, nous vous suggérons d'isoler les informations indépendantes de la langue et de les définir comme des entités dans un fichier séparé qui sera inclus par les différentes traductions. Ceci aide, par exemple, à garder à jour les adresses pour plusieurs fichiers.
autoconf/automake
Conserver à jour les fichiers d'autoconf, config.sub
et config.guess, est critique pour les porteurs, spécialement pour
les architectures plus changeantes. De très bonnes pratiques d'empaquetage
utilisant autoconf et/ou automake ont été regroupées
dans /usr/share/doc/autotools-dev/README.Debian.gz du paquet
autotools-dev. Vous êtes vivement encouragé à lire ce fichier et
à suivre les recommandations indiquées.
Pour diverses raisons, il a toujours été difficile d'empaqueter les bibliothèques. La charte impose plusieurs contraintes pour faciliter la maintenance et pour garantir que les mises à jour sont aussi simples que possible quand une nouvelle version amont est disponible. Une erreur dans une bibliothèque peut rendre défectueux une douzaine de paquets qui en dépendent.
Les bonnes pratiques d'empaquetage des bibliothèques ont été regroupées dans
le guide
d'empaquetage des bibliothèques.
Assurez-vous de suivre les règles sur la
documentation.
Si votre paquet contient de la documentation construite à partir de XML ou SGML, nous vous recommandons de ne pas fournir le source XML ou SGML dans le(s) paquet(s) binaire(s). Si les utilisateurs désirent avoir le source de la documentation, ils peuvent récupérer le paquet source.
La Charte spécifie que la documentation doit être fournie au format HTML. Nous vous recommandons également de la fournir au format PDF et texte simple si c'est adapté et qu'une sortie de qualité raisonnable est possible. Cependant, il n'est généralement pas approprié de fournir des versions en texte simple pour la documentation dont le format source est du HTML.
Les principaux manuels fournis devraient être enregistrés par le paquet
doc-base à l'installation. Reportez-vous à la documentation du
paquet doc-base pour plus d'information.
Plusieurs types spécifiques de paquets ont des sous-chartes spéciales et des règles et pratiques d'empaquetage correspondantes :
Les paquets liés à Perl ont leur charte
Perl, quelques exemples de paquets qui suivent cette charte sont
libdbd-pg-perl (module perl binaire) ou libmldbm-perl
(module perl indépendant de l'architecture).
Les paquets liés à Python ont leur charte Python ; voir
/usr/share/doc/python/python-policy.txt.gz dans le paquet
python.
Les paquets liés à Emacs ont leur charte
Emacs.
Les paquets liés à Java ont leur charte
Java.
Les paquets liés à Ocaml ont leur propre charte que l'on trouve dans
/usr/share/doc/ocaml/ocaml_packaging_policy.gz du paquet
ocaml. Un bon exemple est le paquet source camlzip.
Les paquets fournissant des DTD XML ou SGML devraient se conformer aux
recommandations que l'on peut trouver dans le paquet sgml-base-doc
Les paquets Lisp devraient s'enregistrer avec le paquet
common-lisp-controller pour lequel vous pouvez vous reporter au
fichier /usr/share/doc/common-lisp-controller/README.packaging.
Il n'est pas rare d'avoir une grande quantité de données indépendantes de l'architecture fournie avec un programme. Par exemple, des fichiers audio, une collection d'icônes, des motifs de papiers peints ou autres fichiers graphiques. Si la taille des données est négligeable par rapport à la taille du reste du paquet, il est probablement mieux de tout garder dans le même paquet.
Cependant, si la taille des données est considérable, vous devez envisager de
les partager dans un paquet séparé et indépendant de l'architecture
(« _all.deb »). Ainsi, en faisant cela, vous évitez une duplication
inutile des mêmes données dans onze fichiers .debs pour chaque architecture.
Bien que ceci ajoute une surcharge supplémentaire aux fichiers
Packages, ceci sauve beaucoup d'espace disque sur les miroirs
Debian. Séparer les données indépendantes de l'architecture réduit également
le temps de traitement de lintian ou de linda (voir
Outils du paquet lint, Section A.2)
quand ils sont exécutés sur l'ensemble de l'archive Debian.
Si vous avez besoin d'une certaine locale pendant la construction, vous pouvez créer un fichier temporaire par cette astuce :
Si vous positionnez LOCPATH à l'équivalent de /usr/lib/locale, et LC_ALL au nom de la locale que vous générez, vous devriez obtenir ce que vous voulez sans être root. Quelque chose comme ceci :
LOCALE_PATH=debian/tmpdir/usr/lib/locale
LOCALE_NAME=en_IN
LOCALE_CHARSET=UTF-8
mkdir -p $LOCALE_PATH
localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET"
# Using the locale
LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
Deborphan est un programme pour aider les utilisateurs à détecter quels paquets peuvent être enlevés sans problème du système, i.e. ceux dont aucun paquet ne dépend. L'opération par défaut est de chercher seulement parmi les sections libs et oldlibs pour débusquer les bibliothèques inutilisées. Mais si l'on passe le bon paramètre, il tente d'attraper d'autres paquets inutiles.
Par exemple, avec --guess-dummy, deborphan cherche tous les paquets de transition qui étaient nécessaires pour une mise à jour, mais qui peuvent sans problème être supprimés. Pour cela, il recherche la chaîne de caractères « dummy » ou « transitional » dans la description courte.
Ainsi, quand vous créez un tel paquet, assurez-vous d'ajouter ce texte dans la description courte. Si vous cherchez des exemples, exécutez simplement :
apt-cache search .|grep dummy
or
apt-cache search .|grep transitional
.
orig.tar.gzIl existe deux types d'archives tar (« tarball ») source d'origine : les sources vierges et les sources amont réempaquetées.
La caractéristique définissant une archive source vierge est que le fichier .orig.tar.gz est identique octet-pour-octet à l'archive tar officielle distribuée par l'auteur amont. [30] Cela rend possible d'utiliser des vérifications de somme pour vérifier facilement que tous les changements entre la version Debian et celle de l'amont sont contenus dans le fichier diff Debian. Également, si le source amont est énorme, les auteurs amont et d'autres qui ont déjà l'archive tar amont peuvent économiser du temps de téléchargement s'ils veulent inspecter votre empaquetage en détail.
Il n'y a pas de règles universellement acceptées suivies par les auteurs amont
concernant la structure des répertoires dans leur archive tar, mais
dpkg-source est cependant capable de traiter la plupart des
archives tar comme source vierge. Sa stratégie est équivalente à la
suivante :
Il décompacte l'archive tar dans un répertoire temporaire vide par
zcat chemin/vers/<nom-du-paquet>_<version-amont>.orig.tar.gz | tar xf -
Si, après cela, le répertoire temporaire ne contient qu'un répertoire et pas
d'autres fichiers, dpkg-source renomme ce répertoire en
<packagename>-<version-amont>(.orig). Le nom du
répertoire de premier niveau dans l'archive tar n'a pas d'importance et est
oublié.
Sinon, l'archive tar a dû être empaqueté sans répertoire de premier niveau
commun (honte à l'auteur amont !). Dans ce cas, dpkg-source
renomme le répertoire temporaire lui-même en
<packagename>-<version-amont>(.orig).
Vous devriez envoyer des paquets sources avec une archive tar vierge si possible, mais il peut y avoir diverses raisons pour lesquelles cela n'est pas possible. C'est le cas si l'amont ne distribue pas le source comme un tar gzipé du tout ou si l'archive tar amont contient du matériel non libre au sens des DFSG que vous devez supprimer avant l'envoi.
Dans tous ces cas, le développeur doit construire un fichier .orig.tar.gz convenable lui-même. Nous nous référerons à une telle archive tar comme un « source amont réempaqueté ». Notez qu'un « source amont réempaqueté » est différent d'un paquet natif Debian. Un source réempaqueté est toujours fourni avec des changements spécifiques Debian dans un fichier .diff.gz séparé et il a toujours un numéro de version composé de <source-amont> et de <debian-revision>.
Il peut y avoir des cas où il est souhaitable de réempaqueter le source même si l'amont distribue un fichier .tar.gz qui pourrait en principe être utilisé dans sa forme vierge. Le plus évident est si des économies d'espaces significatives peuvent être réalisées en recompressant l'archive tar ou en supprimant des parties fondamentalement inutiles de l'archive source. Agissez à votre guise à cet endroit, mais soyez prêt à défendre votre décision si vous réempaquetez un source qui aurait pu être vierge.
Un .orig.tar.gz réempaqueté :
doit contenir des informations détaillées sur la façon dont a
été obtenu le source réempaqueté et comment cela peut être reproduit dans le
fichier README.Debian-source ou un fichier similaire. Ce fichier
devrait être dans la partie diff.gz du paquet source Debian,
habituellement dans le répertoire debian, pas dans le
orig.tar.gz réempaqueté. C'est également une bonne idée de
fournir une cible get-orig-source dans votre fichier
debian/rules qui répète le processus, comme décrit dans la Charte,
debian/rules,
le principal script de construction.
ne devrait pas contenir de fichiers qui ne viennent pas de l'auteur amont ou dont vous avez changé le contenu. [31]
devrait, sauf cas impossible pour des raisons légales, préserver l'infrastructure de construction entière et de portabilité fournie par l'auteur amont. Par exemple, ce n'est pas une raison suffisante pour omettre un fichier qui n'est utilisé que pour la construction sur MS-DOS. De manière similaire, un Makefile fourni par l'amont ne devrait pas être réécrit en exécutant un script configure.
(Explication : il est courant que les utilisateurs Debian qui ont besoin de reconstruire un logiciel pour des plates-formes non-Debian récupèrent le source d'un miroir Debian plutôt que de chercher à localiser un point de distribution amont).
devrait utiliser <nom-du-paquet>-<version-amont>.orig comme nom du répertoire de premier niveau dans son archive tar. Cela rend possible la distinction entre des archives tar vierges d'archives réempaquetées.
devrait être gzipé avec une compression maximale.
La façon canonique de réaliser les deux derniers points est de laisser dpkg-source -b construire l'archive tar réempaquetée à partir du répertoire décompacté.
Il est parfois nécessaire de changer des fichiers binaires contenus dans
l'archive tar d'origine ou d'ajouter des fichiers binaires qui ne sont pas dans
celle-ci. Si cela est fait en copiant simplement les fichiers dans
l'arborescence de l'archive debianisée, dpkg-source ne pourra pas
gérer cela. D'un autre côté, selon les règles détaillées ci-dessus, vous ne
pouvez pas inclure un tel fichier binaire modifié dans un fichier
orig.tar.gz réempaqueté. Au lieu de cela, incluez le fichier dans
le répertoire debian dans un format uuencode (ou
semblable) [32]. Le fichier
sera ensuite décodé et copié à son emplacement pendant l'étape de construction.
Le changement sera donc visible assez facilement.
Certains paquets utilisent dbs pour gérer les correctifs à leur
source amont et créent toujours un nouveau fichier orig.tar.gz
contenant le vrai orig.tar.gz dans son répertoire de premier
niveau. Cela est discutable concernant la préférence pour un source vierge.
D'un autre côté, il est facile de modifier ou d'ajouter des fichiers binaires
dans ce cas : placez les simplement dans le fichier
orig.tar.gz nouvellement créé à côté du vrai et copiez les au bon
endroit pendant l'étape de construction.
[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ A ] [ suivant ]
Référence du développeur Debian
[email protected][email protected]