[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]

La Charte Debian
Chapter 2 - L'archive Debian


Le système Debian GNU/Linux est maintenu et distribué sous la forme d'un ensemble de paquets. Très nombreux (plus de 6000), ces paquets sont répartis en plusieurs sections et on leur donne des priorités afin de simplifier leur traitement.

Le projet Debian s'efforce de construire un système d'exploitation libre, mais tous les paquets que nous voulons rendre accessibles ne sont pas libres selon notre définition (voir plus loin les Directives Debian pour le logiciel libre) ou ne peuvent pas être importés ou exportés sans restrictions. L'archive a donc été séparée suivant les sections main, non-free, contrib, non-US/main, non-US/non-free et non-US/contrib. Ces sections sont détaillées plus bas.

Les sections main et non-US/main constituent ensemble la distribution Debian GNU/Linux.

Les paquets des autres sections ne sont pas considérés comme faisant partie de la distribution Debian, bien que nous soutenions leur utilisation à travers notre infrastructure (comme notre système de suivi des bogues et nos listes de diffusion). La Charte Debian s'applique aussi à ces paquets.


2.1 Le copyright des paquets et les sections

Les objectifs de cette section doivent nous permettre de :


2.1.1 Les directives Debian pour le logiciel libre

Les directives Debian pour le logiciel libre (DFSG : « Debian Free Software Guidelines ») suivantes constituent notre définition du logiciel « libre ».

Redistribution autorisée
La licence d'un composant Debian ne doit pas empêcher quiconque de vendre ou de donner ce logiciel en tant qu'élément d'une distribution logicielle qui regroupe des programmes de différentes sources. La licence ne doit pas demander le paiement de droits ou de redevances pour une telle vente.
Code source
Le programme doit inclure son code source et doit permettre sa distribution en tant que code source et comme forme compilée.
Travaux dérivés
La licence doit autoriser les modifications et les travaux dérivés. Elle doit autoriser leur distribution selon les termes mêmes de la licence du logiciel original.
Intégrité du code source de l'auteur
La distribution d'un code source modifié peut être limitée par la licence seulement si des fichiers « patch », joints avec le code source, permettent de modifier le programme au moment de sa compilation. La licence doit explicitement permettre la redistribution de logiciels construits à partir de code source modifié. La licence peut exiger que les travaux dérivés portent un nom différent ou un numéro de version différent du logiciel initial. (C'est un compromis. Le projet Debian encourage tous les auteurs à ne pas limiter les modifications de fichier, source ou binaire.)
Non-discrimination envers des personnes ou groupes de personnes
La licence ne doit faire aucune discrimination à l'encontre d'une personne ou d'un groupe de personnes.
Non-discrimination envers des champs d'activités
La licence ne doit pas empêcher l'usage du programme dans un champ spécifique d'activité. Par exemple, elle ne doit pas empêcher l'utilisation du programme dans le cadre d'une activité commerciale ou pour faire de la recherche génétique.
Distribution de licence
Les droits attachés au programme doivent s'appliquer à tous ceux à qui le logiciel est redistribué sans que ceux-ci aient besoin d'une licence supplémentaire.
La licence ne doit pas être spécifique à Debian
Les droits attachés à un programme ne doivent pas être liés à l'appartenance de ce programme à un système Debian. Si ce programme est extrait de Debian et est utilisé ou distribué sans Debian mais dans les termes de la licence du programme, toutes les parties à qui ce programme a été redistribué doivent avoir les mêmes droits que ceux qui sont accordés avec le système Debian.
La licence ne doit pas contaminer d'autres logiciels
La licence ne doit pas apporter des restrictions à d'autres logiciels distribués avec le logiciel en question. Par exemple, la licence ne doit pas exiger que tous les autres programmes distribués sur le même support soient des logiciels libres.
Exemples de licence
Les licences « GPL », « BSD » et « Artistic » sont des exemples de licence que nous considérons comme libres.

2.1.2 La section « main »

Tous les paquets dans main et dans non-US/main doivent se conformer aux DFSG (« Debian Free Software Guidelines » -- Les directives Debian pour le logiciel libre).

De plus, les paquets dans main

De la même manière, les paquets dans non-US/main


2.1.3 La section « contrib »

Tous les paquets dans contrib et non-US/contrib doivent se conformer aux « DFSG ».

De plus, les paquets dans contrib et non-US/contrib

De plus, les paquets dans contrib ne doivent pas exiger, pour leur compilation ou pour leur exécution, de paquet appartenant à une section non-US.

Voici des exemples de paquets qu'on peut mettre dans contrib ou non-US/contrib :


2.1.4 La section « non-free »

On doit placer dans les sections non-free et non-US/non-free les paquets qui ne se conforment pas aux « DFSG », ou bien les paquets dont la distribution est rendue problématique par des brevets ou des questions légales.

De plus les paquets dans non-free et non-US/non-free


2.1.5 Les sections « non-US »

Certains programmes qui contiennent du code source utilisant la cryptographie doivent être déposés sur le serveur non-US à cause des limitations US à l'exportation. De tels programmes doivent être distribués dans les sections non-US appropriées : non-US/main, non-US/contrib ou non-US/non-free.

Ceci ne s'applique qu'aux paquets qui contiennent du code source utilisant la cryptographie. Un paquet qui contient un programme interfacé avec un programme de cryptographie ou lié dynamiquement à une bibliothèque de cryptographie ne sera pas distribué par le serveur non-us s'il peut fonctionner sans le programme ou la bibliothèque de cryptographie.


2.1.6 Considérations supplémentaires sur le copyright

Tous les paquets doivent être accompagnés d'une copie verbatim de leur copyright et de leur licence dans le fichier /usr/share/doc/paquet/copyright (voir Les informations de copyright, Section 13.6 pour des précisions).

Nous nous réservons le droit d'empêcher l'inclusion de fichiers dans nos archives si

Les programmes dont les auteurs encouragent l'utilisateur à faire des dons conviennent très bien à la section main, sauf si les auteurs affirment que ne pas faire de don est immoral, non éthique, illégal ou quelque chose de similaire ; dans ce cas, ces programmes doivent être placés dans la section non-free.

Les paquets dont les notices de copyright (ou des problèmes de brevet) ne permettent pas la redistribution, même sous forme binaire, et pour lesquels aucune permission spéciale n'a été obtenue, ne doivent pas être placés sur le site FTP de Debian et ses miroirs.

On notera que dans la loi internationale du copyright (ceci s'applique aussi aux États-Unis), aucune distribution ou modification d'un travail n'est autorisée sans une mention explicite. C'est pourquoi un programme sans notice de copyright est protégé et vous ne pouvez rien en faire sans risquer d'être poursuivi. De même, un programme, avec une notice de copyright qui n'énoncerait pas explicitement ce qui est permis, interdit tout.

Beaucoup d'auteurs de soi-disant logiciels libres ignorent les problèmes posés aux utilisateurs par des copyrights restrictifs (ou l'absence de notice de copyright). Il est souvent intéressant de contacter diplomatiquement de tels auteurs pour leur demander de modifier les termes de leur licence. Cependant cela peut être politiquement difficile et vous devriez au préalable demander conseil sur la liste de diffusion debian-legal, comme il est expliqué plus bas.

En cas de doute à propos d'un copyright, envoyez un courrier électronique à debian-legal@lists.debian.org. Soyez prêt à nous donner le copyright complet. Les logiciels couverts par la « GPL », les logiciels du domaine public et les copyrights de type « BSD » sont sûrs ; méfiez-vous d'expressions comme « utilisation commerciale interdite » et « distribution limitée ».


2.1.7 Les sous-sections

Les paquets des sections (main, contrib et non-free sont regroupés en sous-sections pour simplifier leur traitement.

La section et la sous-section seront spécifiées dans le champ de contrôle Section de chaque paquet. Toutefois, le responsable de l'archive Debian peut changer ce choix afin d'assurer la cohérence de la distribution Debian. le champ Section sera de la forme :

Les responsables de l'archive Debian donne la liste des sous-sections autorisées : admin, base, comm, contrib, devel, doc, editors, electronics, games, graphics, hamradio, interpreters, libs, mail, math, misc, net, news, non-US, non-free, oldlibs, otherosfs, science, shells, sound, tex, text, utils, web, x11.


2.2 Les priorités

Chaque paquet aura une priorité spécifiée dans son fichier de contrôle. Cette information, utilisée par l'outil de gestion des paquets Debian, permet de séparer les paquets prioritaires de ceux qui le sont moins.

Le système Debian de gestion de paquet, dpkg, comprend les niveaux de priorités suivants :

required
Ce sont les paquets nécessaires au bon fonctionnement du système. Vous ne devez pas les enlever sous peine de rendre votre système complètement inutilisable ; vous ne pourrez probablement même plus utiliser dpkg pour remettre les choses en place. Les systèmes composés uniquement de paquets required sont probablement inutilisables, mais ils disposent des fonctionnalités suffisantes pour permettre à l'administrateur système de booter et d'installer d'autres logiciels.
important
Ces paquets incluent ceux que l'on s'attend à trouver sur un système de type Unix. Si l'on pense qu'un expert Unix, détectant l'absence d'un programme s'exclamera : « Que se passe-t-il !? où est le programme foo ? », alors celui-ci doit être dans important [6]. Les autres paquets sans lesquels le système ne fonctionne pas bien ou est inutilisable doivent avoir cette priorité. Cela n'inclut pas « Emacs » ou « X11 » ou « TeX » ou tout autre grosse application. Les paquets important constituent simplement un ensemble minimal d'outils nécessaires et communément attendus.
standard
Ces paquets fournissent un système en mode caractère, relativement petit mais pas trop limité. Ils seront installés par défaut si l'utilisateur ne sélectionne rien d'autre. Ce niveau laisse de côté beaucoup de grosses applications.
optional
(En un sens, ce qui n'est pas obligatoire est facultatif, mais ici « optional » ne doit pas être compris ainsi.) Ce sont tous les logiciels qu'on pourrait raisonnablement vouloir installer quand on ne les connaît pas et qu'on a pas d'exigences particulières. Cela constitue un système nettement plus gros et contient « X11 », la distribution complète de « TeX » et de nombreuses applications. Notez qu'il ne doit pas y avoir de conflit entre les paquets optionnels.
extra
Sont regroupés là les paquets qui sont en conflit avec d'autres paquets dont les priorités sont « required », « important », « standard » ou « optional », ou bien les paquets utiles uniquement si vous savez déjà ce qu'ils font, ou bien les paquets qui ont des exigences spécifiques.

Les paquets ne doivent pas dépendre de paquets dont les priorités sont de valeur inférieure (hors dépendances pour la construction). Pour cela, on pourra ajuster les priorités d'un ou de plusieurs paquets.


2.3 Les paquets binaires

La distribution Debian GNU/Linux est fondée sur le système Debian de gestion de paquets, appelé dpkg. Par conséquent, tous les paquets de la distribution Debian doivent être fournis au format de fichier .deb.


2.3.1 Le nom d'un paquet

Chaque paquet doit avoir un nom unique dans l'archive Debian.

Un nom de paquet ne doit comporter que des lettres minuscules (a-z), des chiffres (0-9), les signes plus (+), moins (-) ou point (.). Il doit contenir au moins deux caractères, dont l'un est une lettre.

Le nom d'un paquet fait partie du nom du fichier .deb et est inclus dans le fichier de contrôle du paquet.


2.3.2 Le responsable d'un paquet

Chaque paquet doit avoir un responsable Debian (quelqu'un ou un groupe de personnes, qu'on peut joindre à une adresse électronique, telle que, par exemple, une liste de diffusion). Le responsable assure que la licence du logiciel du paquet suit les règles des distributions auxquelles il appartient.

Le responsable doit être indiqué dans le champ Maintainer avec son nom correct et une adresse électronique valide. Quand une personne s'occupe de plusieurs paquets, elle essaiera d'éviter d'avoir différents noms ou adresses dans les champs Maintainer des différents paquets.

Quand la personne en charge d'un paquet quitte le projet Debian, c'est le groupe Debian QA packages@qa.debian.org qui reprend la maintenance du paquet jusqu'à ce qu'un volontaire se propose pour cette tâche. Ces paquets sont appelés paquets orphelins [7].


2.3.3 La description d'un paquet

Chaque paquet Debian doit avoir une description complète enregistrée dans les champs ad hoc de son fichier de contrôle.

La description apportera les informations dont a besoin un administrateur-système pour décider d'installer le paquet. La description ne reprendra pas simplement la documentation du programme. Les instructions de configuration ou d'utilisation du paquet ne doivent pas en faire partie (c'est le rôle des scripts d'installation, des pages de man, des fichiers infos, etc.), non plus que les notices de copyright et autres écrits administratifs (c'est le rôle des fichiers de copyright).


2.3.4 Les dépendances

Chaque paquet doit indiquer ses relations de dépendance avec les paquets dont il a besoin pour fonctionner correctement.

Par exemple, une relation de dépendance doit être déclarée pour toute bibliothèque partagée qui est demandée par un exécutable dynamiquement lié d'un paquet.

Il n'est pas nécessaire d'indiquer les dépendances d'un paquet envers des paquets étiquetés Essential (voir ci-dessous), et on ne doit pas le faire, à moins que ce ne soit une dépendance pour une version précise de tel paquet.

Dans certains cas, l'installation d'un paquet exige l'installation et la configuration préalables d'un autre paquet. Il faut alors déclarer une relation Pre-Depends pour ce paquet.

Vous ne déclarerez pas une relation Pre-Depends pour un paquet avant qu'une discussion dans la liste de diffusion debian-devel n'ait abouti à un consensus sur le sujet.


2.3.5 Les paquets virtuels

Parfois il y a des paquets qui font plus ou moins la même chose. Dans ce cas, il est utile de définir un paquet virtuel dont le nom décrit la fonction de ces paquets. (Les paquets virtuels existent de manière logique et non physique ; c'est pour cela qu'ils sont appelés virtuels.) Les paquets assurant cette fonction viendront remplir ce paquet virtuel. Ainsi, tout autre paquet qui a besoin de cette fonction pourra simplement dépendre du paquet virtuel, sans avoir à énumérer tous les paquets possibles.

Tous les paquets utiliseront les noms de paquets virtuels quand il conviendra de le faire ; ils s'arrangeront pour en créer de nouveaux quand ce sera nécessaire. On n'utilisera que les paquets virtuels qui ont été acceptés et qui apparaissent dans la liste des noms de paquets virtuels (sauf de manière privée, pour un ensemble local de paquets corrélés).

La version la plus récente de la liste officielle des paquets virtuels se trouve sur ftp.debian.org dans /debian/doc/package-developer/virtual-package-names-list.txt ou sur votre miroir local. Elle est aussi dans le paquet debian-policy. La procédure de mise à jour de la liste est décrite au début du fichier.


2.3.6 Les paquets dans « base »

Les paquets inclus dans la section base ont une fonction particulière. Ils forment le sous-ensemble minimal du système Debian GNU/Linux qui est installé, avant tout autre chose, sur un nouveau système. Ainsi, seulement un tout petit nombre de paquets peut aller dans la section base afin de minimiser la quantité d'espace disque nécessaire à une installation.

La plupart de ces paquets auront le niveau de priorité required ou au moins important et beaucoup d'entre eux seront étiquetés essential (voir ci-dessous).

Vous ne devez placer aucun paquet dans la section base avant qu'une discussion dans la liste de diffusion debian-devel n'ait abouti à un consensus sur le sujet.


2.3.7 les paquets « essential »

Certains paquets sont marqués essential. (Ils ont Essential: yes dans leur champ de contrôle.) Cet indicateur est utilisé pour les paquets qui sont indispensables à un système.

Comme ces paquets ne peuvent pas être facilement supprimés (il faut ajouter une option de forçage de dpkg) l'indicateur essential ne doit être utilisé que si c'est absolument nécessaire. Un paquet comprenant une bibliothèque partagée ne doit pas être étiqueté essential ; les dépendances empêchent sa suppression prématurée, or il doit être possible de la supprimer quand elle est périmée.

Comme dpkg n'empêche pas la mise à jour de paquets alors qu'un paquet essential est non configuré, tous les paquets essential doivent fournir l'essentiel de leurs fonctions même s'ils ne sont pas configurés. Quand un paquet ne peut pas satisfaire à cette exigence, il ne doit pas être étiqueté essential ; et tous les paquets qui en dépendent doivent, comme il est de règle, expliciter leurs dépendances.

Vous ne devez pas étiqueter un paquet comme essential avant qu'une discussion dans la liste de diffusion debian-devel n'ait abouti à un consensus sur le sujet.


2.3.8 Les scripts du responsable de paquet

Les scripts d'installation d'un paquet éviteront d'afficher des messages que l'utilisateur n'a pas besoin de voir et s'appuieront sur dpkg pour sauver de l'ennui un utilisateur qui installe de nombreux paquets. Cela signifie entre autres choses qu'il faut utiliser l'option --quiet de install-info.

Les scripts d'installation doivent détecter toute erreur qui se produit et doivent arrêter immédiatement l'installation en cours.

On remarquera que la section Les scripts, Section 11.4, s'applique généralement aussi aux scripts des responsables de paquet.

On n'utilisera pas dpkg-divert sur un fichier appartenant à un autre paquet sans consulter au préalable le responsable du paquet en question.

Tous les paquets qui donnent une valeur au nom « partagé » d'une commande (en général, c'est un nom de fichier), utiliseront en général update-alternatives, de manière à rendre possible leur installation simultanée. Quand on n'emploie pas update-alternatives, chaque paquet doit utiliser Conflicts pour s'assurer que les autres paquets ne sont pas installés. (On peut spécifier dans ce cas un conflit avec quelques versions antérieures d'un paquet qui n'utilisait pas update-alternatives ; c'est une exception à la règle habituelle qui demande d'éviter les conflits de version.)


2.3.8.1 Poser des questions avec les scripts du responsable

Les scripts du responsable de paquet peuvent interroger l'utilisateur quand c'est nécessaire. On peut interroger « à la main » ou bien par l'intermédiaire d'un programme, tel que debconf, qui se conforme aux règles Debian de gestion de la configuration, version 2 ou supérieure. Ces règles se trouvent dans le fichier debconf_specification du paquet debian-policy. On peut aussi trouver ce fichier sur le site FTP ftp.debian.org dans /debian/doc/package-developer/debconf_specification.txt.gz ou sur un miroir local[8].

Les paquets qui utilisent les règles Debian de gestion de la configuration peuvent contenir un script supplémentaire config et un fichier templates dans leur archive de contrôle. Le script config peut être lancé avant le script preinst et avant que le paquet soit dépaqueté ou bien avant que ses dépendances et pré-dépendances soient satisfaites : il doit donc fonctionner en utilisant seulement les outils présents dans les paquets Essential [9].

Les paquets essaieront de minimiser le nombre de questions posées et s'assureront que chaque question ne sera posée qu'une seule fois. Cela signifie que les paquets doivent essayer d'utiliser les fichiers de configuration partagés (comme /etc/papersize ou /etc/news/server) et les variables partagées de debconf, plutôt que de redemander, chacun, la même information.

Cela signifie aussi que, lors d'une mise à niveau, on ne doit pas poser encore les mêmes questions, à moins que l'utilisateur n'ait utilisé dpkg --purge pour supprimer les fichiers de configuration. Les réponses aux questions de configuration seront sauvegardées à l'endroit approprié dans /etc, et l'on documentera le processus ; ainsi l'utilisateur pourra les modifier.

Quand un paquet doit donner une information importante à l'utilisateur (comme : « ne pas exécuter directement ce programme, vous devez d'abord modifier les fichiers de configuration suivants sinon votre système émettra des messages mal formatés »), il affichera ce message dans le script config ou dans le script postinst). Il demandera ensuite à l'utilisateur de taper sur la touche « retour-chariot » quand il a pris connaissance du message. Les messages de copyright et les instructions d'utilisation ne sont pas considérés comme des messages vitaux. Ils doivent apparaître respectivement dans /usr/share/doc/package/copyright et dans la documentation en ligne, où tous les utilisateurs peuvent les consulter.

Presque toujours, seuls les scripts config et postinst poseront les questions nécessaires ; Quand on utilise le script postinst, il doit empêcher, par une condition quelconque, qu'elles soient posées en cas d'échec de l'installation d'un paquet ou s'il est appelé avec abort-upgrade, abort-remove ou abort-deconfigure.


2.4 Les paquets sources


2.4.1 La conformité aux manuels Debian

On indiquera la version la plus récente de la Charte Debian à laquelle s'est conformé le paquet lors de sa mise à jour la plus récente. Cela se précise dans le champ de contrôle Standards-Version du paquet source. La version actuelle est la version 3.5.6.0.

On peut utiliser cette valeur pour remplir automatiquement des rapports de bogue quand le paquet est vraiment trop vieux.

Le numéro de version est composé de quatre parties : un numéro de version majeur et un mineur, un niveau de patch majeur et un mineur. Quand les normes changent, exigeant des modifications dans tous les paquets, le numéro majeur est changé. Les changements significatifs, exigeant des évolutions dans de nombreux paquets, sont signalés par un changement du numéro mineur. Le niveau majeur de patch sera modifié pour tout changement limité de la signification des standards. Le niveau de patch mineur sera changé pour toute amélioration légère (typographique, ou autres...) qui ne modifie pas le sens de ce document, ou pour des changements qui n'affectent pas le contenu des paquets.

Seuls les trois premiers chiffres de la version sont significatifs pour le champ Standards-Version, et on peut choisir de donner soit les trois chiffres, soit la formule complète [10].

Vous consulterez régulièrement, et notamment si votre paquet est obsolète, la plus récente version de la Charte Debian, et vous mettrez à jour votre paquet si nécessaire. Lorsque le paquet est conforme à la nouvelle norme, vous mettrez à jour le champ Standards-Version du paquet source et vous le diffuserez [11].


2.4.2 Les relations entre paquets

Les paquets source préciseront les paquets binaires qui doivent être installés et ceux qui ne doivent pas l'être, pour que leur construction réussisse. Si l'on doit, par exemple, compiler un paquet avec tel compilateur particulier, une dépendance de compilation sera déclarée envers ce paquet.

Pour un très petit nombre de paquets, ceux dont on a toujours besoin pour compiler, lier et insérer dans un paquet debian un programme classique écrit en C ou C++ comme « Hello world! », il n'est pas nécessaire de déclarer explicitement des relations de dépendance. Ces paquets, sur lesquels on peut trouver des renseignements dans la liste /usr/share/doc/build-essential/list (contenue dans le paquet build-essential), sont marqués build-essential [12].

La liste des dépendances de compilation ne contiendra que les paquets explicitement nécessaires à la compilation. Les paquets simplement demandés parce qu'un paquet de cette liste dépend d'eux ne doivent pas être déclarés [13].

Quand les relations de dépendance de compilation sont indiquées, on doit pouvoir compiler un paquet et produire un binaire opérationnel sur un système où les paquets essential et build-essential sont installés ainsi que ceux nécessaires pour que les relations de dépendance de compilation soient satisfaites (y compris les implicites). Cela signifie en particulier que, dans les relations de dépendance de compilation, on doit traiter rigoureusement les questions de version de manière à éviter les paquets mal ou stupidement configurés quand les relations de dépendances sont correctement satisfaites.


2.4.3 Les modifications dans les « sources » originaux

Si vous modifiez le code source d'une manière qui n'est pas liée au système Debian, vous enverrez ces changements aux auteurs, dans la forme qu'ils préféreront, de manière à ce qu'ils puissent être intégrés dans la version originale.

Si vous avez besoin de configurer le paquet de façon différente sous Debian et sous Linux et si les sources originaux ne proposent pas de manière de le faire, veuillez ajouter ces moyens de configuration. C'est par exemple un nouveau test d'autoconf ou un #define. Envoyez ensuite le « patch » aux auteurs, en choisissant comme valeur par défaut la configuration qu'ils avaient choisie. Vous pouvez facilement remplacer la valeur par défaut dans votre debian/rules ou dans tout autre endroit approprié.

Vous vérifierez que l'outil configure détecte la bonne déclaration d'architecture (reportez vous à la section Les chaînes de spécification d'architecture, Section 12.1 pour plus de détails).

Si vous avez besoin de modifier un Makefile qui utilise des scripts configure de style « GNU », vous modifierez les fichiers .in, plutôt que directement le Makefile. Cela permet à l'utilisateur de reconfigurer le paquet si nécessaire. Vous ne devez pas configurer le paquet et modifier le Makefile produit ! Cela rend impossible la reconfiguration ultérieure du paquet par un autre utilisateur.


2.4.4 Comment documenter vos modifications ?

Vous documenterez vos modifications et vos mises à jour des sources du paquet dans le fichier ad hoc debian/changelog. (Plutôt que de « réécrire l'histoire » en modifiant les vieilles entrées, il vaut mieux corriger les erreurs en créant une nouvelle entrée dans le « changelog ».)

Dans les paquets définitifs, vous devez utiliser, pour debian/changelog, un format supporté par la version la plus récente de dpkg [14].


2.4.5 La détection des erreurs dans les makefiles

Quand make appelle une commande dans un makefile (incluant les makefiles originaux de votre paquet et debian/rules), cela se fait par sh. Or sh traite mal les erreurs : si vous incluez un mini-script shell en tant que commande dans votre makefile, vous constaterez que si vous n'avez pas de mécanisme de détection d'erreur, make continuera aveuglément malgré les problèmes rencontrés.

Chaque fois que vous mettez plus d'une commande shell (cela inclut l'utilisation d'une boucle) dans une commande du makefile, vous devez vous assurer que les erreurs sont détectées. Pour de simples commandes composées comme changer de répertoire et exécuter un programme, il est suffisant d'utiliser « && » à la place du point-virgule. Pour des commandes plus complexes incluant la plupart des boucles et des instructions conditionnelles, vous ajouterez la commande set -e au début de chacun de ces mini-scripts shell que sont les commandes d'un makefile.


2.4.6 Les constructions obsolètes et les bibliothèques

Le fichier d'« include » <varargs.h> est fourni pour les utilisateurs qui compilent des logiciels très anciens ; la bibliothèque libtermcap est fournie pour l'exécution de programmes qui ont été liés avec elle (soit de vieux programmes, soit des programmes comme Netscape disponibles uniquement sous forme binaire).

Les paquets Debian utiliseront plutôt <stdarg.h> et ncurses.


[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]

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