This section by Tom Lees <email@example.com> on Tue, 4 Mar 1997 21:34:57 +0000, with subsequent modifications by Klee Dienes <firstname.lastname@example.org>
This chapter contains general notes about the conversion to
automake. If you plan on doing anything with
you should probably read all of this file first. You have been warned.
Automake has several significant advantages, including:
aclocal utility is a very useful program which will
automatically build an
aclocal.m4 file from the
configure.in file to include the appropriate macros.
This doesn't affect anything other than rebuilding the
files from the sources.
Probably the main difference which is noticable is that instead of using proprietary directory names, it now supports configure --sharedstatedir, and configure --localstatedir. To set these to the Debian defaults, you should use ./configure --localstatedir=/etc --sharedstatedir=/var/lib.
I have also customized the canonicalizing macros found in autoconf to
include the old way of finding the
dpkg ``architecture'', i.e. to
be a bit more smart. Instead of it trying to determine the architecture only,
I changed it to use the `host', `build', and `target' system types. The target
CPU type is checked against the archtable to find the architecture on which
dpkg will run.
It uses gcc --print-libgcc-file-name to find out the build architecture if possible (used later to determine ELF or a.out format), and also uses dpkg --print-architecture if possible to modify the cpu field before it passes on the target alias to config.sub. If you want to specify the architecture, you should now use "--target=", rather than --with-arch, which was essentially a hack anyway. The old --with-arch is still there, but it is somewhat less functional. I have also moved the DPKG_CACHED_ macros into dpkg.m4 to make configure.in a bit more readable.
I also converted to libtool (which can be found in the Debian distribution now). Essentially, this means that all the dpkg tools can be compiled against a shared libdpkg without much hassle (in fact, it is the default). You do not need to install libtool to use this feature (it works like autoconf), and generally, it should not be needed much at all.
The new dist targets will build a distribution including all files
built by the
which are included in the distribution so that people may build
dpkg without these (especially useful to porters).
A target make debian has been added, which will build the Debian files
from a working directory (does a make dist first). Now all we need is
a modified dpkg-source so that the
GNU-distribution file can be used as part of the Debian distribution. I'm
working on this, but it doesn't work too well at the moment (find it in
I removed the make portable target - it doesn't do anything useful.
I have added make uninstall targets to aid non-Debian users who simply want to try out certain Debian packages, and the "dist" targets are also useful to build a "distribution" of the dpkg tool. Note that since automake automatically includes dependencies into the Makefiles in a distribution, if you want to modify the C files, it would be advisable to get and install automake, and then re-run it in the base dpkg distribution directory, so that automatic dependency generation will be switched back on, and any dependencies which change will be taken account of. The "make maintainer-clean" targets will remove all files which any of the following utilities create:
If you want to modify any of the sources, I recommend that you do the following first (after having installed the appropriate utilities, of course):-
I have also incorporated the patches originally made by Galen Hazelwood to internationalize dpkg using GNU gettext - see the file "NOTES.intl" for more information about this.
Other minor changes are:
This section by Galen Hazelwood.
Dpkg is, to say the least, generous in its error reporting. The vast majority of the output strings are error messages of one kind or another. And if you feel that you've stumbled into the Department of Redundancy Department, you would be absolutely correct. Many of the error messages in dpkg.pot are duplicates, used at different points in the program.
To avoid swamping the translators completely, I made some executive decisions on what kinds of strings to translate. All the strings sent to debug() are left alone, on the grounds that these are for dpkg developers, and not for the general public. Most interal error messages were very cryptic, and would probably confuse the translators when seen just sitting there in the dpkg.pot file, and are also left alone. (I did mark some of the more verbose ones for translation.)
If others disagree with me about the necessity of translating these strings, it's easy enough to just go through and mark them later.
I added the startup gettext code to the main routine in dselect, which was necessary as many of the strings in lib are translated. Dselect is otherwise unchanged.
ohshite("error reading from " BACKEND " pipe");
where BACKEND is defined as "dpkg-deb". Because xgettext can't handle this, I have changed this usage in all cases to something like:
ohshite(_("error reading from dpkg-deb pipe");
This isn't very kind to Ian, I know. But what can I do?
dpkg Internals ManualVersion (dpkg 1.9.21)