Hi,
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.
Yes, that should be documented of course.
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.
Depends on the packaging tool, not the distro, so it'll be the same for all rpm-based distros (redhat, suse, ...). dpkg has other variables, but again it should be same for all distros using it (debian, ubuntu, ...). So there shouldn't be *that* many different cases.
rpm sets these:
RPM_PACKAGE_VERSION (upstream version, should be identical to .version) RPM_PACKAGE_RELEASE (downstream version, gets bumbed each time something is changed on the package without upstream version change: patch added, config changed, rebuild with new gcc, whatever ...)
EXTRAVERSION="-${RPM_PACKAGE_RELEASE}" is what (rpm) distros should do for proper build tracking.
cheers, Gerd