Simon Josefsson simon@josefsson.org writes:
- The tarball embeds some username info, some
portability/reproducability TAR_OPTIONS for inspiration:
export TAR_OPTIONS = --owner=0 --group=0 --numeric-owner --sort=name --mode=go+u,go-w --format=ustar
I'm trying this patch:
--- a/Makefile.in +++ b/Makefile.in @@ -648,8 +648,9 @@ distdir: $(DISTFILES) mkdir "$$sd" && $(MAKE) -C $$d distdir="`cd $$sd && pwd`" $@ ; \ done
+TAR_OPTIONS = --owner=0 --group=0 --numeric-owner --sort=name --mode=go+u,go-w --format=ustar dist: distdir - tar cf - $(distdir) | gzip -c >$(distdir).tar.gz + TAR_OPTIONS="$(TAR_OPTIONS)" tar cf - $(distdir) | gzip -c >$(distdir).tar.gz rm -rf $(distdir)
rm_distcheck = test ! -d distcheck-tmp \
My thinking is that
* I want it to be an environment variable, so that it is ignored if tar happens to not be GNU tar (or does other tar programs also use TAR_OPTIONS? Is there some GNU-specific environment variable I could use?)
* I want to set it locally, rather than using the export feature of make, to not have it affect other uses of tar (e.g., it's also used for unpacking in the distcheck target).
* It seems the --no-name option to gzip is not needed when gzip operates in a pipe.
Does that make sense?
I also wonder if there's some *easy* way to fix timestamps. Currently, the dist/distcheck targets copies files into $(distdir), and timestamps will then be the time that copying happens for each file. It's tempting to try to get a timestamp from git, but I prefer of the make rules don't depend on $(srcdir) being a git checkout (e.g., in the make distcheck case, that won't be the case). So I'd need some other source, like a time inside the contents or metadata of some specific file.
Mostly unrelated to this change, this also makes me think about the timestamps of the various stamp files included in the tarball (e.g., stamp-h.in). The make rules dealing with them make my head spin a bit, but I worry that if files get timestamps based on time of copy, they may get in the wrong order so that make from a tarball will want to run autoheader, which defeats the purpose of including that stamp file and config.h.in in the tarball in the first place. Forcing all files to have the same timestamp would probably solve that problem too.
Regards, /Niels