Debian – Creating deb and rpm from the same source

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.

Using different branches is one approach, and I can suggest edits for @mestia’s answer if it seems appropriate (but read on...).

Another approach is to keep different files side-by-side; see Solaar for an example of this.

But both of these approaches have a significant shortcoming: they’re unsuitable for packages in Debian or Ubuntu (or probably other derivatives). If you intend on getting your package in a distribution some day, you should package it in such a way that the same set of files produces the correct result in the various distributions.

For an example of this, have a look at the Debian packaging for Solaar (full disclosure: I did the packaging).

The general idea is to ask dpkg-vendor what the distribution is; so for Solaar, which has different dependencies in Debian and Ubuntu, debian/rules has

derives_from_ubuntu := $(shell (dpkg-vendor --derives-from Ubuntu && echo "yes") || echo "no")

and further down an override for dh_gencontrol to fill in “substvars” as appropriate:

override_dh_gencontrol:
ifeq ($(derives_from_ubuntu),yes)
        dh_gencontrol -- '-Vsolaar:Desktop-Icon-Theme=gnome-icon-theme-full | oxygen-icon-theme-complete' -Vsolaar:Gnome-Icon-Theme=gnome-icon-theme-full
else
        dh_gencontrol -- '-Vsolaar:Desktop-Icon-Theme=gnome-icon-theme | oxygen-icon-theme' -Vsolaar:Gnome-Icon-Theme=gnome-icon-theme
endif

This fills in the appropriate variables in debian/control:

Package: solaar
Architecture: all
Depends: ${misc:Depends}, ${debconf:Depends}, udev (>= 175), passwd | adduser,
 ${python:Depends}, python-pyudev (>= 0.13), python-gi (>= 3.2), gir1.2-gtk-3.0 (>= 3.4),
 ${solaar:Desktop-Icon-Theme}

and

Package: solaar-gnome3
Architecture: all
Section: gnome
Depends: ${misc:Depends}, solaar (= ${source:Version}),
 gir1.2-appindicator3-0.1, gnome-shell (>= 3.4) | unity (>= 5.10),
 ${solaar:Gnome-Icon-Theme}

You can use the test in debian/rules to control any action you can do in a makefile, which means you can combine this with alternative files and, for example, link the appropriate files just before they’re used in the package build.