Package: dpkg-dev Version: 1.21.1 Severity: wishlist File: /usr/bin/dpkg-buildpackage
Dear Maintainer, I'm requesting a flag or environment variable for dpkg-buildpackage and related tools which will allow overriding the version value of the package being produced. Supporting either a build version number suffix or a complete replacement of the build version (or both) would suffice. Use case: I'm working to migrate some internal development workflows to be based on Debian packaging. As a part of this, we may have multiple developers working on the same package concurrently with version numbers to be synchronized at commit time. At some point during the check-in process the version will be changed. Until then there is a need to both be able to build the software into Debian binary packages as well as to install it onto test machines and potentially pass the built packages to other developers for testing. The testing may include building other packages as part of a comprehensive testing process. Consider devlopers A & B who have both checked out the source code to package X at version 1.2.3. Both are actively working on a edit/compile/test loop. At some point during the check-in process the version will be changed to eg. 1.2.4. Developer A wants to be able to validate their work against many different configurations using an automated test runner so they want to upload their version to a central repository from which the test runners can install and test their build for regressions. Developer B instead wants to pass a build of their changes to another developer who will verify that a difficult-to-reproduce issue is addressed with the proposed changes. Importantly, everybody involve should know that the version of the package installed is vaguely related to the original change number, and also be able to separate which version of which is being used on any particular machine. If developer B above then sends their binary for automated testing, it should be clear to anybody exploring failures on the test machines which version of the package was installed at the time test results were captured. Though not omnipresent, some other build systems already support a similar feature. The obvious example is the Linux kernel LOCALVERSION value as briefly mentioned here: https://kernelnewbies.org/OutreachyfirstpatchSetup It's sufficient enough that there is both guidance as well as an independent plugin written to handle this in Gradle: https://stackoverflow.com/questions/24958637/gradle-override-version-property Others such as Maven provide substantially more flexibility when working with the version numbers of packages: https://www.mojohaus.org/versions/versions-maven-plugin/examples/set.html At least for certain usecases RedHat recommends using auto-increment version suffixes on rebuild: https://release-engineering.github.io/pom-manipulation-ext/guide/project-version-manip.html Though not needed for my usercase, there are a number of requests online of various build systems to be able to inject a git commit hash into the package being built. Eg.: https://stackoverflow.com/questions/4942452/how-can-i-add-the-build-version-to-a-scons-build The obvious solution of having developers manually edit the changelog file to accomplish this by hand is absolutely possible. However, good system design works to minimize the number of areas where mistakes or oversights can occur. Thank you for your time, - Garrett
