5

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

3 Answers 3

Reset to default
4

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.

1
  • Thanks, @stephen-kitt! I've been scouring the Web for hours trying to figure out how to use a different source package for a build. I knew it was possible because of the existence of Built-Using. Your gcc-mingw-w64 package is a great example of how to actually do it!
    – Olek Wojnar
    Apr 6, 2021 at 19:55
0

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:

http://packages.debian.org/squeeze/pidgin

[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:

http://www.debian.org/doc/debian-policy/ch-source.html

http://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.html

2
  • 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, 2012 at 6:05
  • 2
    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, 2012 at 14:41
0

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.

1
  • 1
    No, it isn’t designed like that, packages can have different versions.
    – Stephen Kitt
    Apr 7, 2021 at 7:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .