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 fromdebian/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 underlyinggcc-source
(currently,gcc-7-source
) version number and the source package's number. Thus in Debian 9,gcc-mingw-w64
version 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 rundpkg-gencontrol
(or one of its wrappers, such asdh_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 indebian/rules
.The Debian Policy chapter on control fields has more detail on the differences between source and binary control files.