I remember that when I started making Debian packages, one of the things I found more difficult was to get information about how multiple binary packages should be done. It’s quite an important topic when packaging games, as most of games often consist of a small arch-dependent binary executable and a big bunch of arch-independent data that includes images, maps, models, textures, sound, music, fonts and so on.

I order to make it Debian-mirror-friendly, there’s no sense in multiplying all this arch-independent data by the number of architectures in Debian, and thus, most of the games shall be packaged as a small arch-dependent (any) package that includes the game itself, and a bigger arch-independent (all) one with all the data.

I’ve made a small hello-world example to ilustrate how to achieve that. The example uses autotools (1, 2, 3) for building, and consists of a small program that reads an arch-independent text file and prints it to the screen. Small enough to be a nice example, and with all the features needed to show what i mean to.

I won’t comment it in detail right now, but what rules do is to build the program with the default building system (./configure && make), install it in debian/tmp (make install DESTDIR=`pwd`/debian/tmp), and afterwards installing the files in their proper binary package directory. The resulting packages are described in debian/control. The example also includes menu and desktop descriptions and how to install an icon.

We should still find a way to avoid having to release a newer version of the data (usually much bigger in size than the code) when only a change in the code is done, but I doubt if there’s a global solution for that, or if it should be done in an individual per-package way.
Files:

• hello_0.1-1.dsc
• hello_0.1.orig.tar.gz
• hello_0.1-1.diff.gz

That reminds me of a package I made to try to understand how all this works.

May I suggest you rework the debian/rules file?

For instance,

install -d $(CURDIR)/debian/hello/usr/share/pixmaps/
cp debian/*.xpm $(CURDIR)/debian/hello/usr/share/pixmaps/
install -d $(CURDIR)/debian/hello/usr/share/applications/
cp debian/*.desktop $(CURDIR)/debian/hello/usr/share/applications/

should be done using

debian/hello.dirs
debian/hello.install

I hope this helps.

Yup, I guess I should try a newer version with that. Thanks for the comment

Is there any restriction to transform a single binary package into a multiple binary package in order to handle package functionalities added by different extensions?

My case is a single binary currently recommending multiples other packages in order to let you use different extensions.

Is there any policy to make this transformation?

Debian Etch uses automake-1.10, so your example will fail to build as-is. Updating the 4 symlinks from automake-1.9 to 1.10 will fix this.

Thanks Colin, I’ll try to fix that ASAP, thanks for telling me

Thanks for creating the example!
Exactly what I was looking for.
Will try it right away.

To get the debian directory (i.e. apply the diff.gz patch), use:
dpkg-source -x hello_0.1-1.dsc

http://www.xs4all.nl/~carlo17/howto/debian.html

Just in case others are wondering how to do it too.

Sorry for the three consecutive posts, but here’s another link I found useful to understand the first comment ^^:
http://debathena.mit.edu/packaging/

However I was unable to find this info in the official Debian documentation. :/

The file debian/control which defines what binary packages will be built isn’t that a “control” file as it may sound.

Although this file must exist at the beginning of a dpkg-buildpackage run you are free to modify it during the build process later. You can adjust your package definitions dynamically.

I have such a case: One source package creates one binary package on i386 but two binary packages on amd64.

Note (1): debian/control only defines what packages will be *packaged*. It does not (and cannot) control the build process itself (compilation etc). Simplest is, of course, to build all and package only what is needed.

Note (2): One of the first things dpkg-buildpackage (usually) does is to create a new source package. Therefore it packs a debian/control file which does not reflect later changes if such occur. You must ensure this initial debian/control is sufficient for a new dpkg-source -x && dpkg-buildpackage cycle. Beware leaving back an unsuitable control file which may end up in a source package by repeated dpkg-buildpackage runs.

Note (3): Do you want to get a horror show? Unpack gcc source package and look how they are building their debian/control file

Markus

Miriam haz salvado mi vida ^_^
for three days I’m looking for information on how to create multiple
DEBs from a single source file, until I arrived here

voy a probar el ejemplo que creo que es la solución

desde ya muchas gracias (te tendré en cuenta si no lo logro xD)

Saludos
Patricio

Vaya, me alegro de que te sirva. Si tienes cualquier dificultad o cualquier duda, no tengas problema en preguntarme

visit my website, http://osfeio.com, i write about creating package of debian.