On Wed, Sep 04, 2024 at 12:29:55AM +0200, Patrice Dumas wrote: > > > Regardind the dcterms:modified, you may want to increase complexity, > > > trying to make Texinfo builds reproducible.... For me that is a lost > > > cause since the pdftex does not, and won't, make PDF builds reproducible > > > either (and Texinfo depends on (La)TeX). > > > > I am not an expert on reproducible builds and you make a valid point > > about PDF builds not being reproducible. > > > > It appears that pdftex obeys the SOURCE_DATE_EPOCH variable and we > > could do the same for texi2any for EPUB (as mentioned by Werner Lemberg > > on this list). > > I do not think that it would be needed, we only generate EPUB for tests, > and we need to have reproducible tests even more than we need > reproducible builds. We should use TEST customization variable for > that, and would not need SOURCE_DATE_EPOCH. > > To me the issue with dcterms:modified is not about reproducible builds > or reproducible output, the issue is that it is not right to set > dcterms:modified automatically without a possibility for the user to > override the value.
SOURCE_DATE_EPOCH would give the user a chance to override the value and is a standard variable that users might be familiar with, unlike any other variable or option that we might invent. I really don't see what is wrong with using the current date for dcterms:modified by default. Hardly anyone is going to notice or care that it does not correspond to the last date that the manual sources were modified. However, people will notice and have noticed EPUB standard-noncompliance and epubcheck failures.
