Hi Simon, On 2024-05-01 11:36:56 +0200, Simon Josefsson wrote: > Vincent Lefevre <vinc...@vinc17.net> writes: > > IMHO, for additional version information, the Debian changelog is a > > good place for the user + output from a standard command providing > > the version, e.g. "gnulib-tool --version". Scripts can use such a > > command to record the necessary information about software in log > > files. By "standard", I mean that it needs to exist upstream. > > > > For instance, for GCC, there is "gcc --version", where Debian adds > > some information. In particular for gcc-snapshot: > > > > $ gcc-snapshot --version > > gcc (Debian 20240117-1) 14.0.1 20240117 (experimental) [master > > r14-8187-gb00be6f1576] > > [...] > > > > One has all the details... When compiling software, this can be > > found in the generated config.log file, which is really nice for > > bug reports and debugging. > > > > And the gcc-snapshot version string is basically just a date. > > Right. There is one implementation problem: gnulib-tool is patched to > read the version from /usr/share/doc/gnulib/changelog.Debian.gz now, but > if we change changelog to only be a date, we would want to change this > logic to actually print the useful git commit version information, and > I'm not yet sure how to do that.
IMHO, changelog.Debian.gz should contain complete information about the version, not in the Debian package version, but in the log. It already has lines like: * New upstream snapshot from stable branch stable-202401. You may choose some fixed format such that it is parsable by both humans and the machine, i.e. something that a human can understand, but simple enough to that a script can produce a more compact version for gnulib-tool. However, the Debian policy https://www.debian.org/doc/debian-policy/ch-docs.html says Packages must not require the existence of any files in /usr/share/doc/ in order to function.[6] Any files that are used or read by programs but are also useful as stand alone documentation should be installed elsewhere, such as under /usr/share/package/, and then included via symbolic links in /usr/share/doc/package. [6] The system administrator should be able to delete files in /usr/share/doc/ without causing any programs to break. BTW, since gnulib-tool is already in /usr/share/gnulib, it would make sense to have version information there too (perhaps just in the compact form, for gnulib-tool). > There is also the "risk" that upstream gnulib eventually release > versioned archives. There is a recently added v1.0 tag in git for > example, suggesting things may change. Since we haven't used the > 0~20240501* pattern for gnulib version historically, to move to a (Anyway, the 0~20240501* pattern would have been a bad idea, IMHO, because AFAIK, there is no version 0 in gnulib, and that would have confused the user.) > version based approach we would need an epoch like 1:1.3-1 or (more > likely) 1:1.3+20250314-2 since I think we need to package more recent > git commits than what's in any most recent gnulib git tags. However I > don't think the upstream version number is relevant either, for the same > reasons we realized the upstream commit id or branches weren't. So we > can continue to use dates for package versions even if upstream start to > release packaged archives. > > I'm now inclinced to use a pure date-based version string like > 20240501-1 going forward. Any objections? This is OK for me. Until there would be an obvious advantage to change, I'd say that it is better to still use just the date. > We then also have to fix Debian's gnulib-tool --version output to embed > the latest git commit information from upstream that we package -- > possibly using the new git bundle as a source? Instead of parsing > /usr/share/doc/gnulib/changelog.Debian.gz, which may not be present in > stripped down images anyway. Well, you must not use files under /usr/share/doc (see above). I saw that you now ship gnulib.bundle, but I don't know whether this is a good thing (usefulness in practice vs the fact that it makes the package significantly larger). > Since gnulib is a fairly large package, I would prefer to not spam the > archive with new *.orig.tar.gz uploads too often. So I prefer to not > fix this bug until we have to upload a more recent gnulib into the > archive for other reasons. I don't expect that to take long: I'm > planning to do new release of several projects (oath-toolkit, libidn2, > inetutils, etc) that use gnulib, and work on making those Debian > packages use the Debian gnulib package instead of vendored code would > require a new gnulib Debian package upload. OK. I reverted to 20240117+stable-1 on my machines. IIRC, I had installed gnulib to be able to rebuild the libtool package, but a rebuild won't happen until I need to patch libtool. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
