Re: Need some tips on building Debian packages
Paul Johnson wrote:
> While testing
> this out, I realize I've made some mistakes while attempting to revise
> the Makefile to match the packaging requirements. It appears to me
> that I have to 1) move the debian directory to a safe place, 2) erase
> the code tree, 3) untar a fresh copy, 4) copy the debian directory
> back into the source tree, and 5) start over trying to fix the
> Makefile. Is that how you do it? One suggestion I receive is to do
> this work in a directory managed by rcs or subversion. I think that
> would be fine too, but harder to set up when you just want to quickly
> build some small package that somebody distributed for, say, RedHat or
> such. And the Debian diff for the package would then pick up all the
> rcs files, right?
Best is to work with dpatch files. Get a package that has some to see
how it works (so you can read the debian/rules and debian/patches folder
content). You an take libdbi in SID, that I (try my best to) maintain,
as an example.
I don't know how other do, but this is work flow. If other have more
efficient way, please correct me, there's always room for improvements.
Let's say the package is named x in version 1.01.
1 - I detect a patch that has to be done in x.c and x.h, as let's say 2
path have to be adapted to the Debian file system standard. So I first
do "cp x.c x.c.orig" and "cp x.h x.h.orig".
2 - I do whatever changes I want to x.c & x.h. If I do a mistake, I
always have the .orig in case.
3 - When I'm done with testing, I do cd .., then:
diff -u x-1.01/x.c.orig x-1.01/x.c \
>x-1.01/debian/patches/0001-x.c_change_path_to_var_lib_x.dpatch
Then same for x.h
4 - I add the dpatch header by hand to x.c & x.h patches in
x-1.01/debian/patches/ (is there a better way than doing this header by
hand???).
5 - I build the list of patches
6 - I remove the .orig files.
You can do this process as many times as you want, I found that it's
preferable to have one dpatch per original source file, as this minimize
the possibility to fail patching in an eventual new upstream release.
> In a test case I was working on, the build failed because of a
> mismatch between the libtool & automake that were used to create the
> source_orig.tar.gz file and the versions available on the current
> system. As a result, it was necessary to run "autogen.sh" in the
> source directory before trying configure. That process creates a
> bunch of files that should NOT be included in the Debian diff file,
> such as changes in config.sub or such, but the Debian package does
> include those things.
As other said, you can safely erase any file in the debian/rules clean
target, if they are generated during the build (otherwise, they will be
included in the diff.gz). Make it so after a call of "debian/rules
clean" (you can call this on the shell, it works...) your sources are
exactly the same as when you first extracted them.
A very quick test to know that no unwanted files are in the diff.gz is
to do: zcat x_1.01-1.diff.gz | grep +++. This gives you a quick list of
patched files.
> It occurred to me that I could try to work around this by using a
> build directory that is completely outside of the source code tree.
> In many packages that use autotools, we've found it convenient to
> build outside of the source tree and add the --srcdir option to the
> configure command.
This is REALLY the RPM way. Forget about it, it doesn't fit the Debian
system at all, you would complicate things.
> This leaves the source completely unchanged. I've
> not succeeded in doing this while building a Debian package, however,
> because it seems to always want to build stuff in the source tree
> itself. In the process of changing that, I've become confused about
> the sorting of installed files into packages. I'm building library
> packages and haven't yet mastered the problem of installing the files
> into debian/tmp and then using package.listing files to specify the
> files that need to be selected for each Debian package.
As much as I know, the debian/tmp folder is to be forgotten. Use
debian/x instead, as a lib will have to build a libx1-dev and a libx1
package (and eventually a libx-doc). Generally, best option is to use
the upstream Makefile and do:
$(MAKE) install DESTDIR=$(CURDIR)/debian/libx1
in your install target of debian/rules, and later on the same target,
move files, maybe like this if it fits your package:
mkdir -p debian/libx1-dev/usr
mv debian/libx1/usr/include debian/libx1-dev/usr
There are other ways, like using a debian/libx1-dev.install with in it:
include/x/x.h /usr/include/x
and then in the debian/rules file install target, you just delete the
files with rm from the debian/libx folder. Both work, I don't think one
is better than another, maybe try to use the method that will produce
the less number of lines in all the debian files. You are quite free to
use what you want, when doing packaging, as much as I know.
I hope this helped,
Thomas
Reply to: