Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm thinking about properly Debianizing a package, which contains two parts in one upstream tarball/git branch:

  • Userspace binaries and libraries, version 1.5.0 (foobard binary package)
  • Kernel module, version 0.8.5 (foobar-dkms)

The problem is that versions differ. Is there any sane and correct way to build two differently-versioned binary packages from one source package in such case?

If possible, I'd like something cleaner than creating two source packages, or versioning both packages as 1.5.0 (even though the module has proper MODULE_VERSION specified in source).

share|improve this question

migrated from serverfault.com Feb 13 '12 at 20:21

This question came from our site for system and network administrators.

up vote 1 down vote accepted

The version of a binary package in Debian is determined by dpkg-gencontrol, which generates the final control file which ends up in the binary package. The -v option specifies the version number; by default the version number is taken from debian/changelog, but that can be overridden.

There are a few examples of this in the archive; see for example my own gcc-mingw-w64 package, which has its own (source) version number, but generates binary packages whose versions merge the underlying gcc-source (currently, gcc-5-source) version number and the source package's number. Thus in Debian 8, gcc-mingw-w64version 14.3 produces binary packages versioned 4.9.1-19+14.3.

To build different binary packages with different versions from a single source, you'd combine the -v option with the -p option (which specifies the package to process), and run dpkg-gencontrol (or one of its wrappers, such as dh_gencontrol) as many times as necessary.

There is at least package in the archive which demonstrates this: android-sdk-meta builds binary packages with two different versions, android-sdk which takes the source version, and four other packages whose binary version is specified in debian/rules.

The Debian Policy chapter on control fields has more detail on the differences between source and binary control files.

share|improve this answer

In Debian and Ubuntu packages, the version is specified in the debian/changelog file, and it is designed so that all packages generated by a source package have the exact same version.

share|improve this answer

You can check pidgin example. It generates libpurple0, pidgin, pidgin-data, pidgin-dev, pidgin-dbg, finch, finch-dev, libpurple-dev, libpurple-bin packages from one single source.

Get the source from:


[pidgin_2.7.3-1+squeeze2.dsc] [pidgin_2.7.3.orig.tar.bz2] [pidgin_2.7.3-1+squeeze2.debian.tar.gz]

The file that control the build is debian/rules. More info at:



share|improve this answer
It seems that pidgin, pidgin-data, finch and libpurple0 binary packages are all of the same version, for example 2.7.3-1+squeeze2. I know, I can create multi-binary source packages (in fact, I already did it), but only like this — where all generated packages are of same version. – drdaeman Feb 13 '12 at 6:05
You are right! :-( The version comes from changelog file. I will do some testing this week, the first test will have one 'debian' directory for each resulting binary. Same source for all binaries but different 'debian' directory for each one. I'll post the results here. – Peter Senna Feb 13 '12 at 14:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.