D'une manière informelle, l'intégration de « matériel » se fait selon les critères suivants :
Veuillez noter que ces critères ne s'excluent pas mutuellement ; une convention choisie devient souvent une interface standard.
En français, nous employons le verbe « devoir » et ses déclinaisons.
En français, nous employons le futur de l'indicatif et jamais le verbe « devoir ».
Comparez avec la RFC 2119. Remarquez cependant que ces mots sont employés différemment dans ce document.
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ées au cas par cas.
C'est un critère fort, car nous cherchons à produire, entre autres choses, un Unix libre.
La façon élégante de le faire peut être trouvée dans le « Debian Developer's Reference », voyez Documents associés, Section 1.4.
Le commentaire, qui est fourni par un programme dans ses fichiers d'annonces ou dans les 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.
Tiré du Jargon : by hand 2. Par extension, écrire du code pour faire quelque chose explicitement ou à un bas niveau alors qu'une routine de bibliothèque (debconf, dans ce cas) est déjà disponible.
6 % 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 dans l'introduction
à Debconf
: configuration préalable (en particulier), installation
non interactive, élimination des questions redondantes, cohérence de
l'interface utilisateur, etc.
Le nombre croissant de paquets 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.
Le fichier control.tar.gz dans le .deb. Voyez deb(5)
.
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.
Consultez le fichier upgrading-checklist pour connaître les changements entre différentes versions de ce document.
Le raisonnement :
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.
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.
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.
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.
Elle est produite par le programme 822-date
.
Si ce nouveau format reçoit un assentiment 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
.
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.
On ne les détecte pas encore pendant la phase de construction du paquet source, mais seulement pendant la phase d'extraction.
À l'avenir, les liens « en dur » pourraient être autorisés d'une manière ou d'une autre, mais cela demandera beaucoup de travail.
Les répertoires setgid sont autorisés.
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 »
le paquet fakeroot
permet souvent de construire correctement un
paquet tout en n'étant pas root.
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.
Les bases de données internes à dpkg sont aussi des fichiers de contrôle.
Ces paragraphes sont aussi appelés des strophes.
En général, on laisse un espace après le nom du paquet si un numéro de version est spécifié.
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.)
Les caractères alphanumériques sont : A-Za-z0-9
Les lignes complètement vides ne seront pas affichées comme des lignes blanches. Elles induisent plutôt que vous commencez un nouvel enregistrement dans le fichier control et l'analyseur s'arrêtera en constatant une erreur.
Actuellement, les noms des distributions sont les suivants :
On listera toutes les distributions dans lesquelles le paquet sera installé.
Par convention, il y a un espace après chaque virgule.
C'est la partie qui n'est pas .dsc.
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.
Une partie du problème vient certainement d'une erreur de dpkg
.
Replaces est une relation à sens unique -- vous devez installer le paquet remplaçant après le paquet remplacé.
Si vous construisez « build-arch » ou « binary-arch », vous avez besoin de Build-Depends. Si vous construisez « build-indep » ou « binary-indep », vous avez besoin de Build-Depends et de Build-Depends-Indep. Si vous construisez « build » ou « binary », vous avez besoin des deux.
« Build-Depends-Arch » n'existe pas ; les constructeurs automatiques (autobuilders) ont seulement besoin de Build-Depends quand ils savent comment construire uniquement build-arch et binary-arch. Il est supposé que celui qui veut construire les cibles build-indep et binary-indep veut construire le paquet dans son entier et qu'il installe donc toutes les dépendances de construction.
Le but de cette séparation, je m'en rappelle, était que les constructeurs automatiques n'aient pas besoin d'installer les paquets supplémentaires requis par les cibles binary-indep. Mais, sans la séparation build-arch/build-indep, cela ne marchait pas, car le plus gros du travail était fait par la cible build et non pas par la cible binary.
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 des 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.
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.
Les voici :
Pendant une installation ou une mise à jour, le script preinst est appelé avant que de nouveaux fichiers ne soient installés : appeler « ldconfig » est inutile. Le script preinst d'un paquet existant peut aussi être appelé en cas d'échec de la mise à jour. Cela arrive cependant au moment critique où une bibliothèque partagée existe sur le disque sous un nom temporaire. Ainsi, il est dangereux, et c'est interdit par la Charte, d'appeler « ldconfig » à ce moment.
Lors de l'installation ou la mise à jour d'un paquet, le script « postinst configure » s'exécute après que les nouveaux fichiers ont été installés de façon certaine sur le disque. Puisqu'on peut parfaitement appeler sans condition ldconfig dans un postinst, un paquet peut mettre ldconfig dans son postinst sans vérifier les arguments. Le script postinst peut aussi être appelé lors d'un essai de récupération après l'échec d'une mise à jour. Cela arrive avant que les nouveaux fichiers ne soient dépaquetés : il n'y a donc pas besoin d'appeler « ldconfig » à ce moment.
Lors de la suppression d'un paquet, le script prerm est appelé alors que tous les fichiers sont intacts : appeler « ldconfig » est inutile. Les autres appels de « prerm » se passent lors d'une mise à jour, quand tous les fichiers de l'ancien paquet sont sur le disque, et, encore une fois, appeler « ldconfig » est inutile.
D'un autre côté, le script postrm est appelé avec l'argument remove juste après que les fichiers ont été supprimés : c'est le moment idéal pour appeler « ldconfig » et notifier ainsi au système la suppression des bibliothèques partagées appartenant au paquet. Le script postrm peut être appelé à plusieurs moments. Aux moments de « postrm purge », « postrm abort-install » ou « postrm abort-upgrade », appeler « ldconfig » est inutile parce que les fichiers de la bibliothèque partagée ne sont pas sur le disque. Cependant, lorsque le script postrm est appelé avec les arguments « upgrade », « failed-upgrade » ou « disappear », la bibliothèque partagée peut exister sur le disque sous un nom temporaire.
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.
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.
Quand on utilise debhelper, le programme dh_shlibdeps
fera le nécessaire pour vous. Il gérera convenablement les paquets avec
plusieurs binaires.
La commande suivante peut le déterminer :
objdump -p /usr/lib/libz.so.1.1.3 | grep SONAME
C'est ce que fait dh_makeshlibs
de la suite
debhelper.
À l'avenir, l'utilisation de invoke-rc.d
pour appeler les scripts
d'initialisation sera rendue obligatoire. Il est conseillé de passer à
invoke-rc.d aussi tôt que possible.
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.
Les « plug-ins », ces objets internes partagés, chargés dynamiquement
par des programmes en utilisant dlopen(3)
, en sont un exemple.
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.
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.
On peut prévenir l'utilisateur par un message de debconf dont la priorité sera basse, ou bien par un echo (printf).
Argument : Il y a deux problèmes avec les liens « en dur ». Le
premier, c'est que certains « éditeurs » cassent 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.
L'approche traditionnelle pour les fichiers-journaux était d'utiliser « cron » et de simples scripts shell pour monter des combines ad hoc pour la rotation des fichiers. 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 des fichiers-journaux. 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).
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.
Actuellement, dpkg-archictecture
reconnaît 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 ».
Le système Debian de base fournit déjà un éditeur et un pagineur.
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.
Pour utiliser ces fonctions, il faut avoir une dépendance envers liblockfile version >>1.01.
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.
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).
Dans le cadre de cette charte, une « police pour le système X Window » est une police accessible par des requêtes utilisant le protocole X. Les polices pour la console Linux, pour les formateurs PostScript, etc., ne rentrent pas dans cette catégorie. Tous les outils qui rendent disponibles de telles polices pour le système X Window doivent se conformer cependant à cette règle.
Le serveur X peut en effet récupérer des polices sur le système de fichiers local ou, à travers le réseau, sur un serveur de polices pour X ; le système Debian des paquets ne permet que l'utilisation du système de fichiers local.
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.
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.
Dans ce document, on regroupe les deux termes sous le nom de « Motif ».
Ce n'est pas très difficile d'écrire une page de manuel. Voyez le Man-Page-HOWTO
,
la page man(7)
, les exemples créés par debmake
ou par
dh_make
, les programmes d'aide help2man
, ou les
exemples dans le répertoire /usr/share/doc/man-db/examples
.
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.
L'administrateur système pourra supprimer tout fichier dans
/usr/share/doc/
sans craindre de planter un programme.
À ce moment de la transition, nous n'avons plus besoin d'un lien symbolique
vers /usr/doc/
. Plus tard, la charte transformera ces liens
symboliques en bogues.
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.
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.
dpkg
est conçu d'abord pour Debian GNU/Linux, mais peut
fonctionner sur, ou être porté vers, d'autres systèmes.
Il en est ainsi afin que le fichier de contrôle produit possède les bonnes permissions.
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.
Les principales applications de Debian reconnaissent de plus en plus le codage Unicode et particulièrement UTF-8. Ainsi, dans unstable, GNOME 2 l'accepte dans presque tous ses programmes, sauf dans gnome-terminal, qui demande encore des développements pour reconnaître UTF-8 (version disponible dans la distribution « experimental » si vous voulez l'essayer). Au moment de la parution de la distribution « sarge », je pense que la reconnaissance du codage UTF-8 aura atteint la masse critique.
Il me paraît évident que nous devrons passer au codage UTF-8 pour notre infrastructure des paquets. C'est réellement le seul codage adéquat à un environnement international. Mais nous ne pouvons l'utiliser dans les champs des fichiers de contrôle des paquets tant que dpkg n'accepte pas ce codage. On peut malgré tout demander aujourd'hui que les fichiers changelogs soient codés en UTF-8.
Vérifier la présence de caractères n'appartenant pas à UTF-8 dans les changelogs est facile. Passer le fichier dans
iconv -f utf-8 -t ucs-4
, délaisser la sortie et vérifier la valeur de retour. Si des chaînes comportent des séquences qui n'appartiennent pas à UTF-8, iconv s'arrêtera avec un code d'erreur. Ce sera pareil avec la grande majorité des autres jeux de caractères.
La Charte Debian
version 3.6.0.0 Juillet 2003