[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ suivant ]
Ce chapitre a été écrit par Tom Lees mailto:tom@lpsg.demon.co.uk
le
mardi 4 Mars 1997 à 21:34:57 +0000, et comprend de conséquentes modifications
faites par Klee Dienes mailto:klee@debian.org
.
Ce chapitre contient quelques généralités à propos de la conversion à
automake
. Si vous avez l'intention de faire quoi que ce soit avec
dpkg
, vous devriez probablement lire d'abord ce fichier en entier.
Vous avez été prévenu.
automake
possède plusieurs avantages significatifs, parmi lesquels
:
il accepte correctement emacs lisp ;
il accepte correctement libtool ;
il contient l'utilitaire aclocal
.
L'utilitaire aclocal
est un programme très utile qui construit
automatiquement un fichier aclocal.m4
à partir du fichier
configure.in
de façon à inclure les macros appropriées.
Ceci n'affecte rien d'autre que la recompilation des fichiers
Makefile.in
à partir des sources.
La principale différence notable est probablement le fait qu'au lieu d'utiliser des noms de fichiers propriétaires, il accepte maintenant configure --sharedstatedir et configure --localstatedir. Pour faire de ces options des options par défaut pour Debian, vous devriez utiliser ./configure --localstatedir=/etc --sharedstatedir=/var/lib.
J'ai aussi accommodé les macros canonisatrices que l'on trouve dans
autoconf pour inclure l'ancienne façon de trouver
l'« architecture » pour dpkg
, i.e. pour qu'il soit un
peu plus intelligent. Je l'ai modifié pour qu'il utilise les types systèmes
« host », « build » et « target » au lieu de
déterminer seulement l'architecture. Le type de CPU cible est vérifié dans
« archtable » pour trouver l'architecture sur laquelle dpkg va
tourner.
Il utilise gcc --print-libgcc-file-name pour trouver si possible l'architecture de compilation (c'est utilisé ensuite pour déterminer le format ELF ou a.out) ; il utilise si possible aussi dpkg --print-architecture pour modifier le champ cpu avant de passer l'alias de la cible à config.sub. Si vous voulez spécifier l'architecture, vous devriez maintenant utiliser --target=, plutôt que --with-arch, qui n'était de toute façon qu'un « hack ». Le vieux --with-arch est toujours là, mais il est quelque peu moins fonctionnel. J'ai aussi déplacé les macros DPKG_CACHED_ dans dpkg.m4 pour rendre un peu plus lisible le fichier configure.in.
J'ai aussi tout converti à libtool (qu'on peut maintenant trouver dans la distribution Debian). Cela signifie essentiellement que tous les outils dpkg peuvent être compilés avec une librairie partagée libdpkg sans trop de difficultés (en fait, c'est l'option par défaut). Vous n'avez pas besoin d'installer libtool pour utiliser cette fonctionnalité (cela fonctionne comme autoconf), et d'une manière générale, cela ne devrait pas être souvent nécessaire.
Les nouvelles cibles dist construisent une distribution incluant tous
les fichiers construits avec debiandoc2html
,
debiandoc2ps
, etc., qui sont inclus dans la distribution de façon
à ce que les gens puissent construire dpkg
sans eux
(particulièrement utile pour ceux qui font des portages).
Une cible make debian a été ajoutée, qui compile les fichiers Debian à
partir d'un répertoire courant (cela fait d'abord un make dist).
Maintenant tout ce dont nous avons besoin c'est d'un dpkg-source modifié de
façon à ce que le fichier dpkg-1.4.0.8.tar.gz
de la distribution
GNU puisse être utilisé comme une partie de la distribution Debian. Je
travaille là dessus, mais cela ne marche pas très bien pour l'instant (vous le
trouverez dans les exemples).
J'ai enlevé la cible make portable target - elle ne fait rien d'utile.
J'ai ajouté les cibles make uninstall pour aider les utilisateurs non-Debian qui veulent simplement essayer certains paquets Debian ; et les cibles « dist » sont aussi utiles pour construire une « distribution » de l'outil dpkg. Notez que du fait que automake inclut automatiquement les dépendances dans les Makefiles dans une distribution, si vous voulez modifier les fichiers C , il est conseillé de récupérer et d'installer automake, et ensuite de le relancer dans le répertoire de base de la distribution de dpkg, de façon à ce que la génération automatique des dépendances soit remise en marche, et de façon à ce que toute dépendance qui change soit prise en compte. Les cibles « make maintainer-clean » enlèveront tous les fichiers qui sont créés par les utilitaires suivants :
automake
autoconf
aclocal
autoheader
gettextize
libtoolize
Si vous voulez modifier quelque chose dans les sources, je vous recommande de faire d'abord ce qui suit (après avoir installé les utilitaires appropriés, bien sûr) :
make maintainer-clean
aclocal
autoheader
autoconf
gettextize
libtoolize (ne laissez pas automake le lancer, sinon les fichiers libtool ne seront pas inclus dans les cibles dist)
for i in COPYING INSTALL; do ln -s /usr/share/automake/$i .; done
automake
J'ai aussi incorporé les patches créés par Galen Hazelwood qui internationalisent dpkg en utilisant GNU gettext - voyez le fichier « NOTES.intl » pour plus d'information.
Les autres modifications mineures sont :
Le numéro de version est maintenant déterminé par debian/changelog, et non à partir du nom du répertoire.
La création de version.h est maintenant gérée par le script configure, et non par le Makefile.
include/dpkg.h est maintenant produit à partir de include/dpkg.h.in par un script « sed » qui insére les définitions des répertoires appropriées -- il accepte maintenant le changement des répertoires de dpkg (on peut installer dans /usr/local).
Les fichiers « COPYING » (1 petite modification mineure) et « INSTALL » ont été mis à jour à partir de ceux distribués avec automake-1.1l.
Du fait que la librairie partagée libdpkg est maintenant installée, j'ai aussi fait installer par défaut dpkg.h et dpkg-db.h dans /usr/include par include/Makefile.
Questions:
Dois je utiliser localstatedir et sharedstatedir au lieu de sysconfdir et datadir?
Cette section a été écrite par Galen Hazelwood.
Dpkg est, pour le moins, généreux dans ses rapports d'erreur. La grande majorité des chaînes de caractères produites sont d'une manière ou d'une autre des messages d'erreur. Et si vous pensez que vous vous êtes égarés dans le Ministère des Ministères Redondants, vous auriez absolument raison. Beaucoup des messages d'erreurs dans dpkg.pot sont dupliqués et utilisés à différents endroits dans le programme.
Pour éviter de submerger complètement les traducteurs, j'ai pris des décisions arbitraires sur les sortes de chaînes de caractères à traduire. Toutes les chaînes envoyées à debug() sont laissées telles quelles, sur la base du fait qu'elles sont destinées aux développeurs de dpkg, et non à l'ensemble du public. La plupart des messages d'erreur internes sont très cryptiques, et confondraient certainement les traducteurs qui les verraient simplement posés là dans le fichier dpkg.pot, et ils sont laissés tels quels. (J'en ai quand même marqués quelques uns parmi les plus verbeux pour traduction.)
Si d'autres ne sont pas d'accord avec moi sur la nécessité de traduire ces chaînes, c'est suffisamment facile de simplement poursuivre et de les marquer plus tard.
J'ai ajouté le code de démarrage de gettext à la routine principale de dselect, ce qui était nécessaire car beaucoup des chaînes de lib sont traduites. Dselect est à part cela inchangé.
Modifications :
Les fichiers dans intl et po ont été pris de gettext 0.10.26, grâce au programme gettextize. J'ai altéré les makefiles pour enlever le symbole VERSION, qui est utilisé seulement dans les cibles que dpkg n'accepte pas.
aclocal.m4 a été récupéré dans le paquet textutils, configure.in a été altéré pour utiliser ces nouveaux tests, les symboles ont été ajoutés à acconfig.h, et deux nouveaux répertoires ont été ajoutés dans Makefile.in.
Les Makefiles de dpkg, dpkg-deb, md5sum, split, et dselect cherchent maintenant des fichiers d'en-tête (headers) dans ../intl, et essayent de lier avec toute librairie d'internationalisation que configure trouve. Ils définissent aussi maintenant LOCALEDIR dans CFLAGS.
include/dpkg.h possède tous les éléments NLS nécessaires, et le seul fichier qui ne les inclut pas (md5sum/md5sum.c) les comprend directement.
La modification la plus profonde est due à un conflit entre xgettext et le style de codage de dpkg. Bien que xgettext comprenne la concaténation des chaînes constantes, il ne gère pas le cas où les symboles préprocesseur sont utilisés en même temps. Le code de dpkg utilise beaucoup cela, en particulier dans des cas comme celui-ci :
ohshite("error reading from " BACKEND " pipe");
où BACKEND est défini comme « dpkg-deb ». xgettext n'acceptant pas cela, j'ai modifié l'utilisation générale comme cela :
ohshite(_("error reading from dpkg-deb pipe");
Ce n'est pas très sympa pour Ian, je sais. Mais que puis je faire ?
[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ suivant ]
Le manuel de l'intérieur de dpkg
Version 1.5 --- janvier 2001mailto:klee@mit.edu