customdeb − easy modifications to binary Debian packages

I’m currently working at the Linux migration of the city of Böblingen which is currently pushed forward by Itomig. For our modifications to the client there I thought it would be nice to distribute them as easily as the regular Debian packages. We did not want to write a bunch of scripts that modify the files after installation, or try to create packages that modify other packages file.

So I wrote customdeb, which currently allows you to change the contents and permissions of files inside a debian package, generating a new package (with a local version number) that you can easily distribute to your clients. The changes are specified in a simple, debian/control-like file, which therefore also serve as a documentation of your changes. It either modifies a package that you pass it on the command line or tries to fetch it with dget. More ways to change a package (e.g. adjust dependencies) will be added as soon as I need them (or someone else needs them and sends me a patch).

I think this might be useful for others as well, so I am packaging it for Debian. If you want to try it before it went through the NEW queue, you can find the packages here. Contributions are welcome, but be aware that the perl code is currently written in a not very modular, quick-to-work style. I plan to change that if there is more interest in the program. I have the code in a darcs repository (browse it).


Why modify binary debs? Why not just modify the package source and rebuild?
#1 David Fox am 2008-01-28T04:34:39+00:00
Because every source package builds differently, nees build-deps, takes longer, and is not as obvious as modifying the source.
#2 Joachim Breitner (Homepage) am 2008-01-28T17:30:06+00:00
When you modify a package in this way you no longer have an easy way to obtain the source code. This could be easily lead to violations of some open source licenses, or at least to a lot of difficulty fulfilling their terms. I'm just saying...
#3 David Fox am 2008-01-28T20:43:41+00:00
Hmm, that’s a good point. Not a real problem for in-house distribution (as that is not distribution in the GPLL sense), but something to think about.

I wonder if it were sufficient to include the cdeb file used to create the package inside the package, that, together with the unmodified debian source package, would enable anyone to modify the package again.

In any case, the package copyright file should be amended with a notice about the changes.
#4 Joachim Breitner (Homepage) am 2008-01-28T22:53:26+00:00
Could you tell more about the Debian GNU / Linux migration?
I would like to publish a story at http://times.debian.net
Please, send to debian-publicity at lists.debian.org .

What is the current maturity level of customdeb? Is it a more handy tool than the CDD tools?
Also, you could be interested in reading


Andre Felipe Machado
#5 Andre Felipe Machado (Homepage) am 2008-01-28T16:51:15+00:00
The maturity is: it works for the three packages I need it for :-) So I guess that there are quite some bugs to find :-)

About CDD: They differ in the aim in that they want to create policy-compliant packages for public, while customdeb is just an easy way to modify packages for local use.

I’ll tell the main that runs the conversion about times.debian.net.
#6 Joachim Breitner (Homepage) am 2008-01-28T17:33:30+00:00
Very interesting. I need a way to change some configurations for some packages and deploy them to my appliances. For instance, I need to change the Zabbix-Agent config file to point to my servers instead of 'localhost'.

Installing the package and then going back to modify the config on every single machine is a huge pain in the neck. Especially since were human and that means that you cant get it right every time. Would "customdeb" do this?

#7 Richard (Homepage) am 2008-02-05T14:52:42+00:00
Yes, it is pretty much what I do with it.

You write a short file describing your changes (Package name, What files to replace with what data), run customdeb over the original package and get a custom package that has your configuration right out of the box.

BTW, customdeb went through NEW.
#8 Joachim Breitner (Homepage) am 2008-02-05T16:25:24+00:00
<strong>Trackback:</strong> <a href="http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html">How to fork privately</a><br />
A few days ago, I asked how to fork a debian package privately. I got some repsonses by comments, e-Mail and other blog posts, and I want to summarize the tools that were suggested. I have not really tried them, just looked at the webpages, the document
#9 nomeata’s mind shares (Homepage) am 2008-02-11T22:49:14+00:00
Hi, we're using customdeb to modify some packages for our custom ISO and we're facing a problem with using customdeb. Apparently, some packages have a symlink to changelogs in other packages that they're dependant on.fuse-utils is one such package. Customdeb seems to fail when repackaging these specific debs. We tried Any suggestions ?
#10 Udit am 2008-07-24T16:23:25+00:00
I guess this can be considered a bug in customdeb. Probably, in this case the changelog handling should be skipped entirely – patches are welcome. In any case, you should file a bug at bugs.debian.org.
#11 Joachim Breitner (Homepage) am 2008-07-24T22:44:05+00:00
Interesting, is there something similar for source packages? I'd really like to have something that'd

1) automatically build packages with local patches on upgrade

2) show what packages have been modified locally and exactly how

This would be useful for local kernel modifications but also modifications to simpler utilities. Currently I usually just build them in my home directory and install but the problem is that then nobody knows what patches were applied and upgrade to newer version will silently get rid of these patches.
#12 Timo Juhani Lindfors am 2009-09-08T10:41:56+00:00
I’ve been looking for something like that myself, but haven’t found anything. If you know of anything, please tell me :-)
#13 Joachim Breitner (Homepage) am 2009-09-08T11:17:45+00:00

Have something to say? You can post a comment by sending an e-Mail to me at <mail@joachim-breitner.de>, and I will include it here.