D'une manière informelle, l'intégration de « matériel » se fait selon les critères suivants :
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.
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.
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.
Essential est défini comme l'ensemble minimal de fonctionnalités qui doivent être disponibles et utilisables sur le système même quand les paquets sont dans un état non configuré (mais dépaqueté). Cela est nécessaire pour éviter des boucles de dépendances non solutionnables lors des mises à jour. Si des paquets ajoutent des dépendances inutiles sur des paquets de cet ensemble, les possibilités qu'il y aura une boucle de dépendance non solutionnable induite par le forçage de configuration de ces paquets essentiels avant que cela ne soit nécessaire est fortement augmenté. Cela augmente également les possibilités que des frontaux ne seront pas capable de calculer un chemin de mise à jour, même si celui-ci existe.
De plus, il est peut probable qu'une fonctionnalité d'Essential soit jamais supprimée (ce qui est une raison pour laquelle une attention particulière doit être prise avant de faire un ajout à l'ensemble des paquets d'Essential), mais des paquets ont été retirés de l'ensemble Essential quand la fonctionnalité a été déplacée dans un paquet différent. Donc, dépendre de ces paquets au cas où ils ne seraient plus essentiels pose plus de problèmes que cela n'en résoud.
Tiré du Jargon : à la main 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.
Le fichier control.tar.gz dans le .deb. Voyez deb(5)
.
Debconf
ou tout autre outil qui met en œuvre 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 :
on peut ainsi maintenir une liste distincte de la Charte (une liste nécessite moins de contrôle que la Charte) ;
un paquet distinct permet l'installation des paquets « build-essential » sur une machine, et permet aussi que d'autres paquets tels que les tâches installent les paquets « build-essential » à travers une relation de dépendance ;
un paquet distinct permet de séparer les rapports de bogues concernant la liste du processus de gestion de la charte dans le « BTS » (système de suivi des bogues).
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.
Plutôt que de ré-écrire l'histoire en rectifiant les anciennes entrées, il vaut mieux en écrire de nouvelles pour corriger les erreurs de ce fichier.
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 Debian « pure souche ».
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 modification 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 une espace après le nom du paquet si un numéro de version est spécifié.
Dans le futur, il sera permis que le champ Uploaders de
debian/control
(mais pas dans d'autres fichiers de contrôle)
s'étende sur plusieurs lignes et l'interprétation d'un champ Uploaders de
plusieurs lignes devrait être obligatoire.
C'est la valeur la plus utilisée et celle qui est conseillée pour les nouveaux paquets qui ne ne sont pas Architecture: all.
C'est une valeur utilisée dans une minorité de cas, quand le programme n'est pas portable. Et elle ne devrait pas être utilisée pour les nouveaux paquets.
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 :
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.).
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.
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.
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 »).
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é.
Par convention, il y a une 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
.
Note historique : les versions vraiment anciennes (pre-1997) de
dpkg
passaient dans ce cas <unknown> (avec les
signes supérieur et inférieur). Et les plus vieilles versions ne passaient pas
de second argument du tout, quelles que soient les circonstances. Notez qu'une
mise à jour utilisant de telles versions de dpkg ne fonctionnera
vraisemblablement pas, pour d'autres raisons, et même si votre script postinst
gère ce cas.
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 ; ce rôle est essentiellement rempli par les Build-Depends. Il est supposé que celui qui veut construire les cibles build-indep et binary-indep veut de toute façon construire le paquet dans son entier et qu'il installe donc toutes les dépendances de construction. Les constructeurs automatiques (« autobuilders ») utilisent dpkg-buildpackage -B qui appelle build (pas build-arch car il ne sait pas encore vérifier son existence) et binary-arch.
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.
Puisqu'il est courant d'installer plusieurs versions d'un paquet qui fournit des bibliothèques partagées, c'est une bonne idée que la bibliothèque ne contienne pas des fichiers supplémentaires sans version, à moins qu'ils soient placés dans des répertoires qui ont une version.
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 :
/usr/local/lib
/usr/lib/libc5-compat
/lib/libc5-compat
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. Lors de « postrm purge », de « postrm abort-install » ou de « 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 liaison). 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 : supposons 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.
Si vous utilisez GCC, -fPIC produira du code avec du code indépendant de la position relogeable, ce qui est nécessaire pour la plupart des architectures pour créer une bibliothèque partagée, avec i386 et peut-être quelques autres où le code non indépendant de la position est permis dans une bibliothèque partagée..
Le code indépendant de la position peut avoir un impact négatif sur les performance, en particulier sur i386. Cependant, dans la plupart des cas, la perte de performance doit être mesurée par rapport à la mémoire gaspillée sur les quelques architectures où du code non indépendant de la position est même possible.
Parmi les raisons pour lesquelles ceci peut être nécessaire, la bibliothèque peut contenir du code assembleur écrit manuellement qui n'est pas relogeable, l'impact de performance peut être excessif pour des bibltiohèques de calcul intensif et des raisons similaires.
Parmi les raisons pour lier des bibliothèques statiques avec l'option -fPIC, par exemple, on peut avoir besoin d'une API Perl pour une bibliothèque en développement rapide et qui a une API instable, des bibliothèques partagées sont alors sans intérêt à ce moment du développement de la bibliothèque. Dans ce cas, comme perl a besoin d'une bibliothèque avec du code relogeable, il peut y avoir un intérêt de créer une bibliothèque statique avec du code relogeable. Une autre raison citée est si vous distillez plusieurs bibliothèques dans une bibliothèque partagée commune comme le fait mklibs dans le projet de l'installateur Debian.
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 dans la 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 à l'administrateur système. 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).
Quand un paquet est mis à jour et que le propriétaire ou les permissions d'un fichier inclus dans le paquet a changé, dpkg s'arrange pour que le propriétaire et les permissions soient positionnées correctement lors de l'installation. Cependant, cela ne s'étend pas aux répertoires ; les permissions et le propriétaire des répertoires déjà présents sur le système ne changent pas lors d'une installation ou d'une mise à jour de paquet. Cela est logique car, sinon, des répertoires communs comme /usr serait toujours en flux. Pour changer correctement les permissions d'un répertoire appartenant à un paquet, une action explicite est nécessaire, habituellement dans le script postinst. Dans ce cas, une attention particulière doit être prise pour gérer également les mises à jour vers une version antérieure.
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, les chaînes sont : i386 ia64 alpha amd64 armeb arm hppa m32r m68k mips mipsel powerpc ppc64 s390 s390x sh3 sh3eb sh4 sh4eb sparc darwin-i386 darwin-ia64 darwin-alpha darwin-amd64 darwin-armeb darwin-arm darwin-hppa darwin-m32r darwin-m68k darwin-mips darwin-mipsel darwin-powerpc darwin-ppc64 darwin-s390 darwin-s390x darwin-sh3 darwin-sh3eb darwin-sh4 darwin-sh4eb darwin-sparc freebsd-i386 freebsd-ia64 freebsd-alpha freebsd-amd64 freebsd-armeb freebsd-arm freebsd-hppa freebsd-m32r freebsd-m68k freebsd-mips freebsd-mipsel freebsd-powerpc freebsd-ppc64 freebsd-s390 freebsd-s390x freebsd-sh3 freebsd-sh3eb freebsd-sh4 freebsd-sh4eb freebsd-sparc kfreebsd-i386 kfreebsd-ia64 kfreebsd-alpha kfreebsd-amd64 kfreebsd-armeb kfreebsd-arm kfreebsd-hppa kfreebsd-m32r kfreebsd-m68k kfreebsd-mips kfreebsd-mipsel kfreebsd-powerpc kfreebsd-ppc64 kfreebsd-s390 kfreebsd-s390x kfreebsd-sh3 kfreebsd-sh3eb kfreebsd-sh4 kfreebsd-sh4eb kfreebsd-sparc knetbsd-i386 knetbsd-ia64 knetbsd-alpha knetbsd-amd64 knetbsd-armeb knetbsd-arm knetbsd-hppa knetbsd-m32r knetbsd-m68k knetbsd-mips knetbsd-mipsel knetbsd-powerpc knetbsd-ppc64 knetbsd-s390 knetbsd-s390x knetbsd-sh3 knetbsd-sh3eb knetbsd-sh4 knetbsd-sh4eb knetbsd-sparc netbsd-i386 netbsd-ia64 netbsd-alpha netbsd-amd64 netbsd-armeb netbsd-arm netbsd-hppa netbsd-m32r netbsd-m68k netbsd-mips netbsd-mipsel netbsd-powerpc netbsd-ppc64 netbsd-s390 netbsd-s390x netbsd-sh3 netbsd-sh3eb netbsd-sh4 netbsd-sh4eb netbsd-sparc openbsd-i386 openbsd-ia64 openbsd-alpha openbsd-amd64 openbsd-armeb openbsd-arm openbsd-hppa openbsd-m32r openbsd-m68k openbsd-mips openbsd-mipsel openbsd-powerpc openbsd-ppc64 openbsd-s390 openbsd-s390x openbsd-sh3 openbsd-sh3eb openbsd-sh4 openbsd-sh4eb openbsd-sparc hurd-i386 hurd-ia64 hurd-alpha hurd-amd64 hurd-armeb hurd-arm hurd-hppa hurd-m32r hurd-m68k hurd-mips hurd-mipsel hurd-powerpc hurd-ppc64 hurd-s390 hurd-s390x hurd-sh3 hurd-sh3eb hurd-sh4 hurd-sh4eb hurd-sparc
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 œuvre 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 cependant se conformer à 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.
Ces bibliothèques étaient auparavant des liens symboliques. Cependant, avec X11R7, /usr/include/X11 et /usr/lib/X11 sont maintenant des vrais répertoires et les paquets devraient placer leur fichiers à cet endroit plutôt que dans /usr/X11R6/{include,lib}/X11. x11-common (>= 1:7.0.0) est le paquet responsable de la conversion de ces liens symboliques en répertoires.
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ée et cessera d'exister à l'avenir.
L'administrateur système pourra supprimer tout fichier dans
/usr/share/doc/
sans craindre de planter un programme.
Il faut remarquer que cela n'annule pas la section dans les fichiers changelog
et le fichier /usr/share/package/changelog.Debian.gz
doit se référer au changelog de la version courante du paquet en
question. En pratique, cela signifie que la source de la cible et la
destination du lien symbolique doivent être identiques (même paquet source et
même version).
À 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.
Par exemple, /usr/share/common-licenses/Artistic
,
/usr/share/common-licenses/BSD
,
/usr/share/common-licenses/GPL
,
/usr/share/common-licenses/LGPL
,
/usr/share/common-licenses/GFDL
,
/usr/share/common-licenses/GPL-2
et
/usr/share/common-licenses/LGPL-2.1
et ainsi de suite. Notez que
la GFDL est nouvelle ici et que le fichier de licence peut ne pas être encore
en place dans /usr/share/common-licenses/GFDL
.
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.
On peut trouver aujourd'hui un exemple avec le paquet xmms
dont le
champ Depends est utilisé pour l'exéutable xmms, le champ Recommends pour des
extensions (« plug-ins » et le champ Suggests par d'autres
fonctionnalités fournies par unzip.
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.7.2.2