Bruno Haible via Gnulib discussion list <bug-gnulib@gnu.org> writes: > Simon Josefsson wrote: >> Oh, that is neat! But is there any advantage compared to simply using a >> global mtime for all files in the tarball? > > For the specific case of creating a tarball, I see three advantages: > > * When you pick a global mtime for all files, you need to pick it in a > way that is somehow connected to reality. (Using 1980-01-01 for example > is not practically useful, because it confuses every user.) > The way you showed it > $(git log -1 --format=%ct) > ignores built files not under version control (e.g. bison or autoconf > generated) and files modified by the user.
Ignoring them has been my intention - what is the problem with that? I don't think it is possible to come up with a "right" answer to what timestamp to use for each situation. It is possible to advocate for many different values for being the "right" value, each with a credible argument. My inclination is therefor to optimize for lowest complexity. For tarball timestamps, using the same global mtime value for all files in the tarball and make it correspond to when the tarball was prepared (which I'm using the timestamp of the last commit to NEWS as the source for) is simple to implement. And seems to work. > * A typical tarball that uses the GNU Build System needs some timestamp > ordering, in order to build without rebuilding things. In GitHub CI, for > example, I am constrained to use > $ sleep 1; touch aclocal.m4 > $ sleep 1; touch configure > $ sleep 1; touch config.h.in > $ sleep 1; touch `find . -name Makefile.in -type f` > to enforce that order. Having equal timestamps is one timestamp ordering. If I unpack my libidn tarball which is under release preparation and build it, all dependencies are built fine. The tarball use the same mtime for all files. So I don't understand this concern. What problem do you see if you don't perform those steps? There are many artifacts in the libidn release tarball, such as outputs from gengetopt, help2man, fig2dev, texinfo, automake, perl scripts and even outputs from Mono/DotNet programs (which is a reason Guix cannot build the libidn release tarball -- they don't have DotNet because nobody knows how to bootstrap that language any more). I don't recall any timestamp ordering issue when building the tarballs, and I would notice immediately since the tarballs are built in CI/CD on small containers that doesn't have the help2man etc tools. > * The method I'm proposing can be enabled _always_, both for the > "reproducible" case as well as for daily use by ordinary users, > because its results are reasonable even in that second case. I don't understand what this means in practice, do you have any example? I agree that we should incorporate reproducible patterns everywhere. >> Is there any useful use of >> mtime except for dependency tracking triggering 'make' rebuilds? > > I plan to use it for the POT-Creation-Date of .pot files, created by > xgettext. > > Also, when creating documentation that a user expects to be timestamped > (in a footer, like in man pages, or in an annotation, like in PDF files), > it is useful to be able to compute that timestamp in a way that > - matches reality, > - is reproducible, > - does not require user intervention. Yes generated timestamps are complicated, and I'm struggling with those, since it is often surprisingly hard to answer the question "what is the meaning of this timestamp"? Often I've found that there is no meaning, and that a better solution is to remove the timestamp, as in: https://github.com/autoconf-archive/autoconf-archive/pull/323/files /Simon
signature.asc
Description: PGP signature
