La Charte Debian
Footnotes

1

D'une manière informelle, l'intégration de « matériel » se fait selon les critères suivants :

Interfaces standards
Le « matériel » présenté est une interface au système de gestion de paquets dont l'utilisation est obligatoire ; un nombre significatif de paquets l'utilise et elle ne sera pas modifiée sans une étude sérieuse. Les responsables de paquet peuvent donc compter sur la stabilité de cette interface et les auteurs du système de gestion des paquets doivent assurer la compatibilité avec les définitions de ces interfaces. (Le format des fichiers « control » et « changelog » en est un exemple.)
Convention choisie
Quand on a besoin, pour des raisons d'inter-opérabilité, de faire un choix parmi un certain nombre de possibilités techniquement valides. Le numéro de version est un exemple.

Veuillez noter que ces critères ne s'excluent pas mutuellement ; une convention choisie devient souvent une interface standard.

2

En français, nous employons le verbe « devoir » et ses déclinaisons.

3

En français, nous employons le futur de l'indicatif et jamais le verbe « devoir ».

4

Comparez avec la RFC 2119. Remarquez cependant que ces mots sont employés différemment dans ce document.

5

Il se peut que certains paquets ne puissent pas respecter telle règle ; p.ex. les sources ne sont pas disponibles. Ces situations seront examinés au cas par cas.

6

C'est un critère fort, car nous cherchons à produire, entre autres choses, un Unix libre.

7

La façon élégante de le faire peut être trouvée dans le « Debian Developer's Reference », [trad. franç. : Manuel de référence du développeur Debian : <http://www.fdn.fr/~ahulin/>], soit dans le paquet developers-reference, soit sur le serveur FTP Debian ftp.debian.org : /debian/doc/package-developer/developers-reference.txt.gz ou sur la Debian Developer's Reference page web.

8

4 % des paquets Debian [Voir Debconf stats] utilisent debconf pour interroger l'utilisateur au moment de l'installation ; ce nombre augmente régulièrement. Les avantages de debconf sont expliqués rapidement sur Debconf introduction : configuration préalable (en particulier), installation non interactive, élimination des questions redondantes, cohérence de l'interface utilisateur, etc.

Le nombre croissant de paquet utilisant debconf, l'existence d'une implémentation naissante d'un second système Debian de gestion de la configuration (cdebconf) et la stabilisation des protocoles utilisés nous invitent finalement à les mentionner dans la charte.

9

Debconf ou tout autre outil qui met en oeuvre les règles Debian de gestion de la configuration est aussi installé, et toutes les dépendances concernant des versions sont satisfaites avant le commencement de la configuration préalable.

10

Par le passé, on devait donner la formule complète à quatre chiffres, par exemple : « 2.3.0.0 ». Mais comme un changement de niveau de « patch » n'introduit pas une nouvelle norme, on a trouvé préférable d'assouplir la règle et de ne demander qu'une formule à trois chiffres, dans ce cas : « 2.3.0 ». (On peut toujours utiliser la formule complète si l'on veut.)

11

Consultez le fichier upgrading-checklist pour connaître les changements entre différentes versions de ce document.

12

Le raisonnement :

13

La raison en est que les relations de dépendance changent et vous ne déclarerez que les paquets et seulement ceux-là dont vous avez besoin. Ce dont les autres ont besoin est leur affaire. Si par exemple vous utilisez la bibliothèque libimlib, vous aurez besoin d'une dépendance de construction pour le paquet libimlib2-dev ; mais vous n'avez pas besoin de dépendance pour les paquets libjpeg*, même si libimlib2-dev dépend de ces paquets : l'installation de libimlib2-dev s'assurera que toutes les dépendances nécessaires à son exécution sont satisfaites.

14

Si vous souhaitez utiliser un autre format, vous pouvez le faire tant que vous fournissez un outil d'analyse (parser) dans votre paquet source. Cet outil doit avoir une API compatible avec celle attendue par dpkg-genchanges et par dpkg-gencontrol. Quand ce nouveau format recueille un intérêt partagé, vous contacterez le responsable de dpkg afin qu'il ajoute le script analyseur de votre format dans le paquet dpkg. (Vous accepterez ainsi que l'analyseur et sa page de manuel soient distribués sous la licence « GNU GPL », comme l'est le reste du paquet dpkg.)

15

Actuellement, les noms des distributions sont les suivants :

stable
C'est l'édition d'une version à jour de Debian GNU/Linux. Une fois que la distribution est stable, seule la correction d'erreurs majeures ou d'erreurs concernant la sécurité est autorisée. Quand cette distribution est modifiée, son numéro d'édition est incrémenté (par exemple : 1.2r1 devient 1.2r2 puis 1.2r3 etc.).
unstable
Cette valeur de distribution fait référence au côté développement de l'arbre Debian des distributions. Les nouveaux paquets, de nouvelles sources pour les paquets et la correction d'erreur vont dans le répertoire unstable. C'est prendre des risques que d'utiliser cette distribution.
testing
Cette valeur de distribution fait référence au côté test de l'arbre Debian des distributions. Les paquets qui la composent proviennent de la distribution unstable où ils sont restés un court moment de manière à s'assurer qu'ils n'ont pas de défauts graves. Les paquets de cette distribution sont moins défectueux que ceux de la distribution unstable mais comportent des risques. On ne peut pas installer des paquets dans testing.
frozen
De temps en temps, la distribution testing entre dans un état dit de « gel du code » qui anticipe la version stable. Pendant cette période de test, seules les corrections d'erreurs existantes ou nouvellement découvertes sont autorisées. Le détail précis de cette étape est déterminé par le responsable de l'édition (« Release Manager »).
experimental
Les paquets qui possèdent cette valeur de distribution sont considérés par leur responsable comme représentant un grand risque. Souvent, ce sont des paquets en phase béta ou en cours de développement, provenant de sources variées que les responsables veulent faire tester, mais ce ne sont pas des paquets qui peuvent être inclus dans d'autres répertoires de l'arbre Debian des distributions. À utiliser à ses risques et périls.

On listera toutes les distributions dans lesquelles le paquet sera installé.

16

Les caractères alphanumériques sont : A-Za-z0-9

17

Le raisonnement est que la connaissance de l'âge d'un fichier apporte certaines informations ; par exemple, on peut reconnaître l'ancienneté de telle documentation en regardant la date de modification. Et donc il serait bon de préserver les dates de modifications des fichiers sources.

18

Une autre façon de faire est que build dépende de build-stamp sans rien faire d'autre, et que build-stamp fasse le travail et se termine par touch build-stamp. C'est particulièrement utile si la routine crée un fichier ou un répertoire appelé build ; build doit alors être déclaré comme une cible .PHONY. Consultez la documentation de make pour des renseignements sur les cibles « phony »

19

le paquet fakeroot permet souvent de construire correctement un paquet tout en n'étant pas root.

20

Bien que rien n'empêche un auteur qui est aussi le responsable Debian d'utiliser ce fichier pour tous les changements, il faudra modifier son nom si les responsables Debian et les auteurs deviennent différents. Mais dans ce cas, il vaudrait mieux considérer le paquet comme n'étant pas un paquet « pure souche » Debian.

21

les valeurs habituelles pour urgency sont : low, medium, high et emergency. Elles influent sur la rapidité avec laquelle on envisagera l'installation du paquet dans la distribution testing et elles donnent une indication de l'importance des corrections contenues dans cette mise à jour.

22

Pour être précis, cette chaîne doit correspondre à l'expression rationnelle Perl suivante :

     /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i

Alors tous les numéros de bogues listés seront fermés par le script de maintenance de l'archive (katie), ou, dans le cas d'une mise à jour par un suppléant du responsable (Non-maintainer-upload), seront marqués comme corrigés.

23

Elle est produite par le programme 822-date.

24

files.new est utilisé temporairement par dpkg-gencontrol et dpkg-distaddfile ; ils écrivent une nouvelle version de files avant de le renommer, pour éviter de laisser une copie corrompue, si une erreur se produit.

25

On ne les détecte pas encore pendant la phase de construction du paquet source, mais seulement pendant la phase d'extraction.

26

À l'avenir, les liens « en dur » pourraient être autorisés d'une manière ou d'une autre, mais cela demandera beaucoup de travail.

27

Les répertoires setgid sont autorisés.

28

Le commentaire, qui est fourni par un programme dans ses fichiers d'annonces et/ou fichiers README, est rarement approprié pour une utilisation dans une description. Il est habituellement conçu pour les gens qui connaissent déjà le paquet...

29

Qu'une erreur arrive -- l'utilisateur interrompt dpkg ou bien quelque chose d'imprévu se passe -- il ne faut pas laisser un paquet défectueux à l'utilisateur quand dpkg essaye de refaire l'action.

30

Une partie du problème vient certainement d'une erreur de dpkg.

31

Le système de gestion des paquets demande que la bibliothèque soit placée avant le lien symbolique qui pointe vers elle dans le fichier .deb. Ainsi, avant que dpkg n'installe le lien symbolique (en remplaçant le lien précédent qui pointe sur une version plus ancienne de la bibliothèque), la nouvelle bibliothèque est déjà en place. Par le passé, on créait la bibliothèque dans le répertoire temporaire où l'on faisait le paquet avant de créer le lien symbolique. Malheureusement, cela ne marchait pas toujours car la construction du fichier tar pour le fichier .deb dépendait du système de fichier sous-jacent. Des systèmes de fichiers (comme reiserfs) réordonne les fichiers de sorte que l'ordre dans lequel on les crée est oublié. Avec sa version 1.7.0, dpkg réordonne, si nécessaire, les fichiers lors de la construction d'un paquet. Et il n'est plus nécessaire de se préoccuper de l'ordre de création des fichiers.

32

Les voici :

33

Par le passé, on appelait ldd pour connaître les bibliothèques partagées requises ; maintenant on appelle objdump. Le seul changement dans la manière de construire un paquet est que l'on doit aussi exécuter dpkg-shlibdeps sur les bibliothèques partagées, alors qu'avant ce n'était pas nécessaire. La suite de cette note explique les avantages de cette méthode.

Un binaire foo utilise directement la bibliothèque libbar quand il est lié explicitement à cette bibliothèque (c'est à dire qu'il utilise le drapeau -lbar pendant la phase de liage). Les autres bibliothèques dont libbar a besoin sont liées indirectement à foo, et l'éditeur de liens dynamiques les charge automatiquement quand il charge libbar. Un paquet dépendra des bibliothèques qu'il utilise directement, et les dépendances de ces bibliothèques amèneront automatiquement les autres bibliothèques.

Malheureusement, le programme ldd indique toutes les bibliothèques, celles directement utilisées et celles indirectement utilisées ; ce qui signifie que les dépendances comportent des dépendances directes et indirectes. Avec objdump, on évite ce problème en indiquant seulement les bibliothèques directement utilisées.

Voici un exemple qui montre l'intérêt de ce système : on pourrait mettre à jour libimlib avec une version qui accepte le nouveau format graphique dgf (tout en gardant le même numéro majeur de version). En utilisant l'ancienne méthode ldd, chaque paquet qui se sert de libimlib devrait être recompilé pour qu'il dépende aussi de libdgf, sinon il ne marcherait pas à cause de symboles manquants. Mais, avec le nouveau système, les paquets qui se servent de libimlib peuvent dépendre simplement de libimlib qui possède elle-même la dépendance envers libdgf et ils n'auront pas besoin d'être mis à jour.

34

Un exemple nous aidera : disons que le paquet source foo produit deux paquets binaires, libfoo2 et foo-runtime. Pour la construction de ces paquets, on utilise les répertoires debian/libfoo2 et debian/foo-runtime respectivement (on pourrait utiliser debian/tmp à la place de l'un des deux). Puisque libfoo2 fournit la bibliothèque partagée libfoo, il demandera un fichier shlibs qui sera installé dans debian/libfoo2/DEBIAN/shlibs, et deviendra finalement /var/lib/dpkg/info/libfoo2.shlibs. Maintenant, quand on exécute dpkg-shlibdeps pour l'exécutable debian/foo-runtime/usr/bin/foo-prog, dpkg-shlibdeps examine le fichier debian/libfoo2/DEBIAN/shlibs pour savoir si les dépendances de foo-prog en ce qui concerne les bibliothèques sont satisfaites par les bibliothèques fournies par libfoo2. Pour cette raison, on ne doit exécuter dpkg-shlibdeps qu'après que tous les fichiers shlibs de chaque paquet binaire ont été installés dans le répertoire de construction.

35

Quand on utilise debhelper, le programme dh_shlibdeps fera le nécessaire pour vous. Il gérera convenablement les paquets avec plusieurs binaires.

36

La commande suivante peut le déterminer :

     objdump -p /usr/lib/libz.so.1.1.3 | grep SONAME

37

C'est ce que fait dh_makeshlibs de la suite debhelper.

38

Argument : compiler par défaut avec l'option -g gaspille davantage de cycles CPU puisque les informations sont de toute manière enlevées ; cela peut avoir un impact significatif sur l'efficacité des autobuilders. Une façon standard de construire des variantes avec des informations de débogage facilite la construction de binaires ou de bibliothèques puisqu'elle permet de documenter la façon d'obtenir ce genre de compilation ; on ne doit pas avoir à modifier «  à la main » debian/rules ou des Makefiles.

39

Vous pourriez aussi utiliser les options --remove-section=.comment et --remove-section=.note sur les bibliothèques partagées et sur les exécutables, et l'option --strip-debug sur les bibliothèques statiques.

40

Les « plug-ins », ces objets internes partagés, chargés dynamiquement par des programmes en utilisant dlopen(3), en sont un exemple.

41

Sans doute, libtool peut faire de l'édition de liens avec des bibliothèques qui n'ont pas de fichier .la ; mais, n'étant qu'un simple script shell, il peut augmenter considérablement le temps de compilation d'un paquet s'il doit, pour chaque bibliothèque et chaque fois qu'elle est liée, déduire tous ces renseignements des premiers principes. Avec l'apparition de «libtool-1.4 (et dans une moindre mesure de libtool-1.3), les fichiers .la gardent des renseignements sur les dépendances entre bibliothèques qui ne peuvent pas être nécessairement déduits une fois détruit le fichier .la.

42

Le nom-so est le nom du fichier objet partagé : c'est ce qui, entre le moment de la construction de l'exécutable et celui de son fonctionnement, doit être exactement le même pour que l'éditeur de liens dynamiques soit capable de faire marcher le programme. Par exemple, si le nom-so de la bibliothèque est libfoo.so.6, le paquet de la bibliothèque sera appelé libfoo6.

43

La charte Debian indique que /bin/sh suit la norme POSIX, mais echo -n est largement utilisé dans la communauté Linux (dans cette charte, dans les sources du noyau Linux, dans beaucoup de scripts Debian, etc.). Ce mécanisme est valable mais n'est pas demandé par POSIX, d'où cet ajout explicite. D'autre part, la rumeur dit que ce mécanisme doit devenir de toute façon obligatoire sous LSB.

44

On peut le trouver sur http://www.cpan.org/doc/FMTEYEWTK/versus/csh.whynot ou sur ftp.cpan.org dans /pub/perl/CPAN/doc/FMTEYEWTK/versus/csh.whynot.

45

Argument : Il y a deux problèmes avec les liens « en dur ». Le premier, c'est que certains « éditeurs » casse le lien quand ils modifient l'un des fichiers, et les deux fichiers peuvent devenir involontairement différents. Le second, c'est qu'il arrive que dpkg casse le lien pendant une mise à jour de conffiles.

46

L'approche traditionnelle pour les fichiers d'écoute était d'utiliser « cron » et de simples shell scripts pour monter des combines ad hoc pour la rotation des fichiers d'écoute. Cette approche, grandement paramétrable, demandait beaucoup de travail au sysadmin. Bien que le premier système Debian ait apporté une aide en installant automatiquement un système qui pouvait être pris comme modèle, cela ne fut pas considéré comme suffisant.

Une meilleure idée est d'utiliser logrotate, un programme développé par Red Hat, qui centralise la gestion de l'écoute. Il possède à la fois un fichier de configuration (/etc/logrotate.conf) et un répertoire où les paquets peuvent déposer leurs configurations pour la rotation des fichiers, (/etc/logrotate.d).

47

Les fichiers ordinaires (à l'exception des conffiles et d'autres fichiers similaires) installés par dpkg ont normalement leurs droits réinitialisés avec les droits de la distribution lors de la réinstallation d'un paquet. Cependant, l'utilisation du programme dpkg-statoverride annule ce comportement par défaut. Si vous utilisez cette méthode, vous penserez à décrire ce programme dans la documentation du paquet ; en tant qu'apport relativement récent à Debian, il est probablement peu connu.

48

Actuellement, dpkg-archictecture reconnait les architectures et les systèmes d'exploitation suivants : les architectures : arch est l'une des valeurs suivantes : alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sh, sheb, sparc et sparc64. Les systèmes d'exploitation : linux, gnu, freebsd et openbsd. L'utilisation de gnu dans cette chaîne est réservé pour le système d'exploitation « GNU-Hurd ».

49

Le système Debian de base fournit déjà un éditeur et un pagineur.

50

Quand il n'est pas possible d'établir les deux modes de verrouillage, le système ne doit pas attendre que le second mode soit mis en place, mais doit enlever le premier mode, attendre un certain temps et recommencer le verrouillage.

51

Pour utiliser ces fonctions, il faut avoir une dépendance envers liblockfile version >>1.01.

52

Cela met en oeuvre la pratique actuelle et offre une vraie politique pour l'utilisation du paquet virtuel xserver, lequel apparaît dans la liste des paquets virtuels. En résumé, les serveurs « X » qui communiquent directement avec le matériel d'entrée et d'affichage ou via un autre sous-système (p.ex. GGI) fourniront xserver. Des choses comme Xvfb, Xnest et Xprt ne doivent pas le faire.

53

Une nouvelle fenêtre de terminal ne signifie pas nécessairement une nouvelle fenêtre X de plus haut niveau directement liée au gestionnaire de fenêtres ; elle pourrait être, si l'application qui émule le terminal était codée ainsi, une nouvelle « vue » dans une interface pour plusieurs documents (MDI, multiple-document interface).

54

Dans le cadre de cette charte, une « fonte pour le système X Window » est une fonte accessible par des requêtes utilisant le protocole X. Les fontes pour la console Linux, pour les formateurs PostScript, etc., ne rentrent pas dans cette catégorie. Tous les outils qui rendent disponibles de telles fontes pour le système X Window doivent se conformer cependant à cette règle.

55

Le serveur X peut en effet récupérer des fontes sur le système de fichiers local ou, à travers le réseau, sur un serveur de fontes pour X ; le système Debian des paquets ne permet que l'utilisation du système de fichiers local.

56

Ce mécanisme n'est pas identique à celui d'app-defaults ; les fichiers app-defaults sont liés au binaire client du système de fichiers local, alors que les ressources X sont stockées dans le serveur X et influencent tous les clients qui se connectent.

57

Les programmes qui utilisent Imake sont dispensés car, tant qu'ils sont correctement écrits, les chemins qu'ils utilisent pour localiser les ressources et s'installer sont tirés entièrement de la configuration du système X Window. Et donc, au cas où le système X Window bougerait vers /usr/X11R7/, /usr/X12/ ou juste un simple /usr/, les paquets n'auraient qu'à être recompilés avec les paquets de développement des bibliothèques du système X Window.

58

Dans ce document, on regroupe les deux termes sous le nom de « Motif ».

59

Cette faculté demande à man un temps de calcul déraisonnable pour trouver une page de manuel, rapporter qu'elle n'existe pas et transférer dans sa base de données une information qui devrait rester dans le système de fichier. Elle est déconseillé et cessera d'exister à l'avenir.

60

Ces liens symboliques seront détruits un jour, mais ils doivent exister pour des raisons de compatibilité jusqu'à ce que tous les paquets aient pris en compte cette règle et que la charte debian soit changée en conséquence.

61

Le script de debhelper, dh_installdocs fait ça automatiquement.

62

Le raisonnement : ce qui importe ici, c'est que les documents HTML soient disponibles dans certains paquets, et pas nécessairement dans le paquet binaire principal.

63

Argument : on n'a pas à chercher dans deux endroits les « changelogs » originaux simplement parce-qu'ils ont des noms différents ou parce qu'ils sont dans un format HTML.

64

dpkg est conçu d'abord pour Debian GNU/Linux, mais peut fonctionner sur, ou être porté vers, d'autres systèmes.

65

Cela signifie : ils s'exécutent correctement ou échouent ; mais, s'ils sont appelés de nouveau, ils ne doivent pas se planter, mais s'assurer que tout est à sa place.

66

Ce champ apparaîtra dans tous les paquets, même si dpkg n'en a pas besoin, afin que les vieux paquets puissent être toujours installés.

67

L'idée est que la connaissance de l'âge d'un fichier apporte certaines informations ; par exemple, on peut reconnaître l'ancienneté de telle documentation en regardant la date de modification. Et donc il serait bon de préserver les dates de modifications des fichiers sources.

68

Il en est ainsi afin que le fichier de contrôle produit possède les bonnes permissions.

69

Dans une prochaine version de dpkg, dpkg-shlibdeps serait aussi appelé pour les bibliothèques partagées. Ils peuvent être spécifiés soit dans les emplacements de l'arborescence source où ils sont créés soit dans les emplacements de l'arborescence temporaire de construction où ils sont installés avant la création du paquet binaire.

70

Bien qu'il n'y ait rien qui empêche un auteur qui est aussi le responsable Debian de l'utiliser pour tous les changements, il devra être renommé si les auteurs et les responsables Debian deviennent physiquement différents.

71

Elle est créée par le programme 822-date.

72

files.new est utilisé temporairement par dpkg-gencontrol et dpkg-distaddfile ; ils écrivent une nouvelle version de files avant de le renommer, pour éviter de laisser une copie corrompue, si une erreur se produit.

73

On ne les détecte pas encore pendant la phase de construction du paquet source, mais seulement pendant la phase d'extraction.

74

À l'avenir, les liens « en dur » pourraient être autorisés d'une manière ou d'une autre, mais cela demandera beaucoup de travail.

75

Les répertoires setgid sont autorisés.

76

Changer le nom d'un fichier n'est pas traité spécialement. C'est vu comme l'effacement d'un ancien fichier (qui provoque un avertissement, mais il est ignoré autrement) et la création d'un nouveau.

77

Les caractères @ : = % _ (at, deux-points, égal, pourcent, souligné) étaient autorisés et sont toujours acceptés quand ils sont trouvés dans un fichier de paquet, mais ne doivent pas être utilisés dans les nouveaux paquets.

78

C'est une erreur

79

En général, on laisse un espace après le nom du paquet si un numéro de version est spécifié.

80

Par convention, il y a un espace après chaque virgule.

81

C'est la partie qui n'est pas .dsc.


La Charte Debian

version 3.5.6.1 cvs 1.68 03/2002
Ian Jackson ijackson@gnu.ai.mit.edu
Christian Schwarz schwarz@debian.org
révision : David A. Morris bweaver@debian.org
La liste de diffusion « Debian Policy » debian-policy@lists.debian.org