@civodul @jas4711 A somewhat relevant example is how...

@civodul @jas4711 A somewhat relevant example is how the NEWS file is checked, but there are other examples.

As for “and distributions could package the gnulib git repository (up to some current version)”, I’m not sure it would be easy, because git allows itself to re-pack its objects whenever it wants, so further steps may be needed for the content of the .git repository to remain reproducible over time.

Like 2 April at 9:59 | Wall-to-wall | Open on mastouille.fr

7 comments

Vivien the Trumpeting Elephant

@civodul @jas4711

Finally, I think we should not forget that the modification time of the .texi file impacts the modification date that is printed in the final output of the manual. Setting it to 1970 is awkward in this case.

2 April at 10:00 | Open on mastouille.fr

Simon Josefsson

@gugurumbe @civodul Having modtime influence PDF output seems bad - can’t we use a @DATE@ macro set at ./configure-time that the .texi file @include? It should probably the time of the last commit to the project.

2 April at 10:13 | Open on infosec.exchange

Vivien the Trumpeting Elephant

@jas4711 @civodul I think you have to look through the git log to find the latest commit that affected the manual in a non-trivial way, because the last-modified date can also be used to detect documentation drift.

2 April at 10:17 | Open on mastouille.fr

Vivien the Trumpeting Elephant

@jas4711 @civodul Another option I considered to avoid the dependency on git is to have another syntax-check that would check that you also changed the modification date of the manual in the most recent commit that modified it. It’s harmless to skip this check if you have a shallow clone of the repository or not have git installed.

2 April at 10:53 | Open on mastouille.fr

Simon Josefsson

@gugurumbe @civodul How does .git content changing break ability to include the entire git repository in Debian’s gnulib package?

2 April at 10:15 | Open on infosec.exchange

Vivien the Trumpeting Elephant

@jas4711 @civodul It would be difficult to consider the .git repository as source code, if it’s just a big bunch of binary blobs that can change for unclear reasons.

2 April at 10:21 | Open on mastouille.fr

Simon Josefsson

@gugurumbe @civodul binary blobs that can change for any reason sounds awfully similar to other binary packages in Debian.

2 April at 10:27 | Open on infosec.exchange