How do I patch a Debian package

Posted by Serge on Sat 24 Sep 2005 at 07:28

I've been looking into the new maintainer howto, to try and understand how I should properly patch an existing Debian package, in case a Sarge package rsync.

I'm being confronted with a rather anoying bug in rsync, which totally brakes rsnapshot for me. Read all about that in #317418.

Although I quite understand what Debian "stable" is all about, I fail to understand how a non-security bug, that nevertheless severely breaks a package, is not solved in Debian stable. But that's only a sidenote.

My other readings went to, as always, the very nice articles here, in particular this article rebuilding Debian Packages.

I wanted to patch rsync-2.6.4 with the patch I linked to in my bug report, to solve my rsnapshot problem. I tried it and thought I did well. The resulting package built without errors and can be found here:

The problem is, the bug remains :) I suspect the patch didn't get applied.

Basically what I did was update the changelog and saving the patch in debian/patches. I suppose there is something more to do as to tell the system to use that patch, but that tiny little detail isn't clear in the New Maintainers howto.

Even more, the examples presented never clearly explain my situation where one wants to patch an existing deb.

I also found it quite confusing when the manual explains different 'patch systems' (debuild, others, ...) I'm not sure why there are different systems.

I hope this brings an interesting view for the more advanced debian developer to understand which part of the new maintainer manual isn't quite clear. But then again, it might just be me :)

A lot of explanation, but what I want to ask is if somebody would have a look on my custom package and explain me the detail of what I missed. Thanks!



Posted by Steve (82.41.xx.xx) on Sat 24 Sep 2005 at 07:30
[ View Steve's Scratchpad | View Weblogs ]

Two quick comments:

  • Nobody can look at your package if you only provide the .deb file. We'd need to see the source from which it was produced.
  • I suspect that rsync ignores the debian/patches directory - a quick scan of the source had no obvious references to it. If so your assessment that the patch wasn't applied appears valid.

If that is the problem get the source:

mkdir /tmp/rsync/
cd /tmp/rsync/
apt-get source rsync
cd rsync-*

Make your changes (ie. apply the patch).

Then run debuild, and ignore the patches directory.


[ Parent | Reply to this comment ]

Posted by JulienV (83.196.xx.xx) on Sun 25 Sep 2005 at 09:37
[ View Weblogs ]
I would suggest that you have a look at dpatch(1).

Basically, you just need to change the debian/rules file to use dpatch:
- Create a debian/patches directory
- Edit a debian/patches/00list file where you put the list of the patch you want to apply
- Create the patch template using dpatch patch-template:
dpatch patch-template -p "01_some_patch" "A random patch" \
- Edit the debian/rules file: you first need to source the dpatch rules ('include /usr/share/dpatch/dpatch.make'), and make use of them (clean calls unpatch, build calls patch etc.) - reading man pages is really worthy is this case!

Hope this can help.

[ Parent | Reply to this comment ]

Posted by Serge (213.118.xx.xx) on Mon 26 Sep 2005 at 07:16
[ View Serge's Scratchpad | View Weblogs ]
After following Steve's tips, all went smooth. I indeed needed to manually patch the source, which was the simplest as I only had to add 3 lines of C code. An automated patching was not setup in this case for this package.
I updated the packages on

One question remains: how do I make a source deb with those now?
I also wrote an antry on my blog about why this was important to me: (shameless plug) ated/

Thanks for all the help.


Serge van Ginderachter

[ Parent | Reply to this comment ]

Posted by broonie (212.50.xx.xx) on Mon 26 Sep 2005 at 13:31
dpkg-buildpackage will make a source package (consisting of a .dsc, .diff.gz and .orig.tar.gz for non-native packages) for you while building the package when invoked with the default options.

[ Parent | Reply to this comment ]

Posted by maurits (80.126.xx.xx) on Mon 26 Sep 2005 at 19:24
I heartily recommend the (unofficial I guess) Debian Package Customization HOWTO by Roberto C. Sanchez. I have happily used that to apply a patch to the rss2email package. Thanks Roberto!

[ Parent | Reply to this comment ]

Posted by undefined (192.91.xx.xx) on Mon 26 Sep 2005 at 22:23
somebody mentioned dpatch, but unless the debian maintainer has already added the framework to the package, or you intend to maintain this package (adding & removing patches yourself), dpatch is too much overhead for a single patch. but if you do it, please send a patch to the debian maintainer; they may appreciate it.

but i really must recommend pbuilder if you do much building of packages (whether one package multiple times or several packages). i use pbuilder to build/backport packages on my testing desktop for my stable server.

works great even for building software that you are not going to package, but just going to tarball: build, install, & tarball it in the pbuilder chroot, then untar it on the server. i use a chroot because i usually have to muck with the configure or make files to get everything to install properly under /usr/local and i don't like doing this trial & error process on my server. sure, a plain chroot is all that's needed, not pbuilder's, but if you are already using pbuilder for building debian packages, might as well use pbuilder for this too.

[ Parent | Reply to this comment ]

Posted by Anonymous (81.57.xx.xx) on Tue 27 Sep 2005 at 15:54

And now the remaining question is ...

How to have this well intregrated with automated updates ?

(ie. in case of a security update, do you want you're package to be overwritten ? will you remember this modification in 5 years when etch will be out ?).

[ Parent | Reply to this comment ]

Posted by Serge (194.78.xx.xx) on Tue 27 Sep 2005 at 16:03
[ View Serge's Scratchpad | View Weblogs ]

You probably do not want updates to overwrite them.
Pinning your package will avoid your package to be upgraded. Manually monitoring and backporting your fix would be the only way I think.


Serge van Ginderachter

[ Parent | Reply to this comment ]

Posted by rhertzog (2a01:0xx:0xx:0xxx:0xxx:0xxx:xx) on Tue 5 Jul 2011 at 10:55
You might also be interested in this article of mine that provides more recent information in particular to take into account the new source format "3.0 (quilt)".

[ Parent | Reply to this comment ]

Sign In







Current Poll

Should this site stay open?

( 1602 votes ~ 24 comments )



Related Links