Debian – Two differently-versioned binary Debian packages from one source

debianpackaging

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).

Best Answer

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-7-source) version number and the source package's number. Thus in Debian 9, gcc-mingw-w64version 19.3 produces binary packages versioned 6.3.0-18+19.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 one 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.

Related Question