Simon Josefsson <si...@josefsson.org> writes: > I think that solution is covering up the real problem. I believe there > is no universal "right" timestamp to put in a man page that you can > guess from a generator tool like pod2man. I believe the timestamp is > part of the documentation, and IMHO should be provided in the input > files or on the command-line.
Okay, I can see the appeal of that. I don't think I can help achieve that goal as a maintainer of the generator program, though, unfortunately. There isn't really a lever that I can pull to push things in that direction other than forcing a date to be provided as part of the interface, which is an extremely backward-incompatible change that would break the world and therefore isn't really feasible. There is already a flag for people to set the date if they want to, but they have to use it. Another option is to follow Ian's suggestion and just remove the date entirely by default. I suppose I could make that change in the generator program and it *probably* wouldn't break anything that significant, but it's the sort of change I'm a bit leery about making because I don't have any good way of polling what my downstream users want and pod2man has added the date for about 30 years. That's a lot of time for it to become accidentally load-bearing, or at least strongly desired, by someone. > Consider a simple package containing two man pages. One is for a tool > that frequently change and is re-factored and updated on every release. > The other is for a tool that has been stable and never has changed. > I think using the SOURCE_DATE_EPOCH timestamp in both man pages is not > helpful. Doing so solves the reproducibility problem at the expense of > the purpose of the information (to tell when it was last modified). For whatever it's worth, with my upstream hat on, I think the behavior that I would ideally want is for both man pages to receive a date matching the last release date of the package. I understand why someone might instead want it to be the last change of the tool, but I prefer to bump dates and versions with releases even if there wasn't a change affecting that program, in large part for the practical reason that figuring out if there was a change to the tool is often annoying and tedious and I would rather spend my development cycles on something else. Either way, I agree that's not what we get with SOURCE_DATE_EPOCH right now. The SOURCE_DATE_EPOCH behavior was a replacement for the previous behavior of always using the mtime of the file, which has even more problems including obvious reproducibility problems. I realize this may be plastering over a bug, but I would argue that it was a pretty good plaster that got us a long way with a minimally-invasive change. :) If someone wants to tackle fixing all the build systems to make release date information more readily available, that would be great, and I would be very happy to use it in my packages. (gnulib is a good start!) I'm not seeing how we can readily add this at the Debian packaging step, though, so I don't think this helps with the more immediate problem. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
