On Thu, Oct 22, 2015 at 04:16:04PM +0200, Gerd Hoffmann wrote:
Hmm, just noticed that only git builds are considered being "clean". That implies builds from release tarballs will *not* be considered clean. Was that intentional?
My thinking was that it is too easy for a ".version" file to be inadvertently incorrect. That is, if one pulls down a release tarball and then modifies some files, the version in the binary is not going to reflect the fact that changes were made.
I didn't think it would be too painful to require the git repo for those desiring a reproducible build. The "git describe" tool is quite useful for getting a meaningful hash of the repo.
Do you think that will be a problem?
Linux distro builds usually use release tarballs (plus possibly patches) not git checkouts. Having timestamp and hostname back in the version string then is a step backwards. Will have only the effect that distros start patching the build system again ...
One option I see is to consider builds clean in case EXTRAVERSION is present, so distros can simply set EXTRAVERSION to the rpm release.
So, consider the build clean if git does not exist, ".version" does exist, and EXTRAVERSION is set? That seems reasonable, if a bit convoluted. The key would be letting distribution builders know about this and to document what information we expect to be contained in the EXTRAVERSION field.
Or add a new variable specifically for package build versioning, and possibly even set that automatically. rpm sets some environment variables in the build environment ....
That's also possible (buildversion.py could check for common package building environment variables), but I suspect that different distros use different variables.
-Kevin