Re: Need some tips on building Debian packages
* Paul Johnson <pauljohn32@gmail.com> [080530 22:08]:
> Keep in mind that my background is in RPM building, where the emphasis
> is on distributing "pristine" source code. I was initially
> shocked/dismayed by the Debian approach because the source code gets
> untarred and fiddled with by the packager. Some of the example guides
> that people referred me to may have been bad examples--packagers were
> opening the source directory and liberally applying patches and making
> changes, and all of those fiddles were getting wrapped up into the one
> big diff file, making it impossible to figure out who did what.
Please note that this is all a matter of perspective. I'm shocked
every time trying to look at source prms, which are very effective in
both hiding the pristine source and the differences from me. (As opposed
to the Debian way, where you are supposed to have the original pristine tar
file and cleary seperated differences in unversaly readable format.)
The format has indeed a serious disadvantage that done natively in
a single patch without additional descriptions, it is hard to read this,
but unlike source rpms, it is at least getable without needing special
programs or magic perl scripts.
> There's not much information on
> how to manage patches in the Debian New Maintainer's Guide,
Ideally, you do not need patches at all, or only temporary until
upstream includes them. Thus I think a longer descriptions would be
out of scope for the New Maintainer's Guide. (Though the description
in Developer's Reference looks a bit too shot, perhaps it should be
modernized a bit).
> I keep wondering, "If the goal is to re-distribute 'pristine' source
> code and patches, why doesn't Debian discourage users from untarring
> the sourced code?"
I don't understand. Why should anyone want to not unpack the source
code? How are you supposed to build it without source code?
> Why can't you make it so the debian directory is
> not inside the source tree?
What advantages would this have? It would needlessly complicate the
format, makeing it harder for people to see what we have changed.
> After configuring those, I try to do a package build. 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.
Why do you think you need to do this?
> 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?
You can tell dpkg-source (or dpkg-buildpackage which you will usually call
to call dpkg-source for you) to exclude some files using the -i option.
> 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.
In the Debian aproach you have to supply a clean target in debian/rules
that undoes all the changes you did to it. If you run autogen.sh
(or autoreconf if it is a modern enough package), you just delete
all the files in generates/renews in the clean target.
Having the single .diff.gz file is an advantage here: you just take
a look at it (for example using diffstat) and see what was modified
in your build.
> 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 leaves the source completely unchanged.
This is indeed a possible way and many Debian packages do this.
But many upstream build systems do not support this (even autotools
using packages are often buggy in that regard).
And for the majority of packages this is not needed, as it is a very
absurd thing for a build system to modify the source and not properly
clean up after it. (And it is very easy to catch, just take a look at
the diff).
> 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.
Try again then. Using something like produced by dh_make, it should
mostly be replacing the ./configure call with a
mkdir builddir && cd builddir && ../configure
(and replacing the generated file from configure.status to
builddir/configure.status, of course) and not calling $(MAKE) later
but $(MAKE) -C builddir
Hochachtungsvoll,
Bernhard R. Link
Reply to: