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 _______________________________________________ SeaBIOS mailing list [email protected] http://www.seabios.org/mailman/listinfo/seabios
