Bruno Haible via Gnulib discussion list <bug-gnulib@gnu.org> writes: > Simon Josefsson via Gnulib discussion list wrote: >> +EXTRA_DIST += $(top_srcdir)/.version >> +BUILT_SOURCES += $(top_srcdir)/.version >> +$(top_srcdir)/.version: >> + echo '$(VERSION)' > $@-t >> + mv $@-t $@ > > Wait a moment. Before putting this into a Makefile fragment, we should > fix it first. > > 1) I claim that it is over-engineered. Why are there 2 files that contain > the version, '.tarball-version' and '.version'? And which is the original > one, which is the copy? > > The answers are contained in the .git-version-gen file as comments, but I > still have problems remembering them.
When I read the explanation in git-version-gen it make sense. Is it possible to simplify anything? The files are for different purposes -- .version for Makefile dependency tracking, and .tarball-version for git-version-gen to do the right thing when the tarball is being built. However, you have a point, it seems the .version file doesn't have anything to do with git-version-gen at all, does it? It is never used by the script. Maybe a doc/git-version-gen.texi is the answer here... and thinking through the concepts a bit more. > 2) You want to have reproducible tarballs, right? Look at the .version files > in coreutils and gettext releases: ... > Look especially at coreutils-7.6, coreutils-8.4, coreutils-8.9, > coreutils-8.13, > gettext-0.21, gettext-0.21.1. > > It appears that the .version file contains the version number of the *last* > "make dist" invocation the maintainer did in the particular directory > *before* making the final "make dist". Which is clearly a thing that is not > derived from what is checked into git. > > Put another way: It is desirable, for reproducibility, that in a release > tarball, .tarball-version and .version have the same contents. If neither > Pàdraig nor I succeed in ensuring this property, there is clearly something > wrong with the way these two files are defined. Good catches. However, is this a current problem? I believe the GNUmakefile '_version' rule which is triggered on 'make release' solves this. If it doesn't, that's a bug which should be fixed. How were those buggy releases prepared? It is hard to know that now. Did the maintainer really follow README-release strictly? I doubt it. The only way to really be sure is to continously do 'make release' etc in CI/CD from fresh git and compare with your local tarballs. I do this for several projects (libidn, libtasn1, inetutils, ...), and for inetutils I get reproducible tarballs (with some uncommitted fixes). I'm having serious problems getting releases out the door due to some small nit causing tarball reproducibility problems, or messing up the release process.... But .version and .tarball-version files has not been involved in any reproducibility problem that I've noticed. Of course, if it is possible to find a 'make release' workflow that create incorrect .version and/or .tarball-version files we should fix that. Or tighten up README-release. /Simon
signature.asc
Description: PGP signature
