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és 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 », [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.
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.
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.
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.)
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.
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
.)
Actuellement, les noms des distributions sont les suivants :
On listera toutes les distributions dans lesquelles le paquet sera installé.
Les caractères alphanumériques sont : A-Za-z0-9
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.
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.
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
.
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.
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.
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...
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.
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 :
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.
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.
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.
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.
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 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
.
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.
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).
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
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 ».
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 « 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.
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.
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 ».
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.
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.
Le script de debhelper, dh_installdocs
fait ça
automatiquement.
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.
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.
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.
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.
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.
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.
Elle est créée par le programme 822-date
.
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.
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.
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.
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.
C'est une erreur
En général, on laisse un espace après le nom du paquet si un numéro de version est spécifié.
Par convention, il y a un espace après chaque virgule.
C'est la partie qui n'est pas .dsc.
La Charte Debian
version 3.5.6.1 cvs 1.68 03/2002ijackson@gnu.ai.mit.edu
schwarz@debian.org
bweaver@debian.org
debian-policy@lists.debian.org