Re: Need some tips on building Debian packages
Hi Paul
I have also found the migration from RPM packaging to Debian packaging
to be a hard one (I'm *not* a mentor, BTW). Some of my observations include:
1. Whereas RPM provides one key tool, 'rpmbuild', Debian packaging
seems to provide dozens of different tools, not all of which are
used by all users, with the result that different packagers will
tell you different packaging techniques that seem to have, at
times, little or no common elements.
2. Whereas an RPM can be generated at a minimum with one 'special'
file (the .spec file) that can basically be typed by hand, Debian
packages seem to provide half a dozen 'special' files: 'rules',
'changelog', 'control', man pages, etc etc, many of which are best
to be auto-generated by scripts, because of their complexity.
3. For people who are packaging their own code, the 'rpmbuild -ta'
command is really nice, and makes rapid standalone packaging /so/
much simpler. This allows you to put your packaging files in with
your source code, making 'developer's own' binary releases much
simpler.
4. RPM's support for multiple platforms/distros/arches is, to me,
more intuitive. I can write a *single* .spec file that builds
distinct RPMs for OpenSUSE, Fedora, RHEL and Mandriva, just using
conditional pre-processor statements. That sort of thing seems, on
first inspection, to be rather difficult to achieve with Debian.
Again, this is of value to those developers who are also
attempting to provide binary packages for their users, especially
for simple packages that don't have too much distro-specific stuff
to worry about.
If it's of any interest, I wrote a little Python script that appealed to
my RPM sensibilities, while hopefully producing fully compliant Debian
packages. Any feedback would be welcome; it's still under development.
http://ascendwiki.cheme.cmu.edu/Dtar
Essentially, this script just provides the 'rpmbuild -ta' functionality,
but also allows you to package your 'meta files' in a separate tarball
('debian.tar.gz'). This is reasonably compatible, FWIW, with the way
that the OpenSUSE Build Service allows you to package Debian packages.
You still need to generate all those 'rules', 'changelog', etc, files.
One thing I will say about Debian, though, is that writing the above
'dtar' tool was very easy, because of the excellent Python packages that
are available for parsing the variable Debian packaging metafiles.
Cheers
JP
Paul Johnson wrote:
> Hi I'm new here.
>
> I've been asking around for help on building debian packages. I've
> been building RPMS for about 1 decade, but never tried to build a
> Debian package. As preparation, I've read through the New
> Maintainer's Guide and miscellaneous other web pages. I came in
> through the Ubuntu door. My friends forwarded some questions to a
> person in your list, who suggested I ask here.
>
> 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.
>
> I eventually found out that these were bad examples. At the end of
> the day, the recommendation for Debian packaging is essentially the
> same as in RedHat: we are aiming to distribute unchanged source that
> is patched in a clear and orderly way. There's not much information on
> how to manage patches in the Debian New Maintainer's Guide, but in
> section 6.4 it does acknowledge the problem and refers to dpatch.
>
> 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?" Why can't you make it so the debian directory is
> not inside the source tree? One response I've received is that "we
> are not RedHat, try to get over it."
>
> I wonder how you do your day-to-day work on building debs? I have
> followed the dh_make approach of opening the source, and dh_make gives
> me template files in "debian" for control, rules and such. I
> understand completely that all these different files are just doing
> the same thing as the one big SPEC file does in an rpm framework.
> 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. 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?
>
> 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 building RPMS, the source code patches are applied, but the output
> from autogen and configure is not wrapped up into the changes that are
> packaged.
>
> 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. 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.
>
>
Reply to: