Hi Simon, On 2024-04-19 09:13:01 +0200, Simon Josefsson wrote: > Vincent Lefevre <vinc...@vinc17.net> writes: > > > Package: gnulib > > Version: 20240412~dfb7117+stable202401.20240408~aa0aa87-2 > > Severity: normal > > > > A long package version is annoying for the user (for the "dpkg -l" > > output and other reasons). I doubt that such a long version is > > necessary;
I would also add that long version strings are truncated in the aptitude TUI due to the limited terminal width. > Hi Vincent and thanks for the report. > > Yeah, I can sympathise with this concern, and deciding on the version > scheme probably took me the most time in the last update. Some > discussion would help. Quoting README.source: [...] Thanks for the explanations. However, I think that it is not the goal of the Debian version string to entirely reflect all the Debian-side and upstream-side versions involved. This may be a good idea when the obtained version string is short enough and easy to understand, but here, this is not the case. There are probably better places to give such information, in a clearer way. This could be in well-chosen files and/or output from commands like "gnulib-tool --version" (see below). > The only superflous information in the version strings are the dates, > but removing them does not seem like it would improve on your concern, > rather the opposite. Maybe the dates are what makes sense for users. > > And something like dates are needed for dpkg version ordering. Yes, for version strings, dates are much more important than things like commit ids (which just look like random characters). > Some ideas for improvement: > > 20240411+stable-1 - revert to earlier pattern, this loses the commit id > information and which stable branch was used, potentially making it > impossible to use the same pattern in the future if there is one Debian > upload of 20240411+stable-1 and somehow upstream gnulib commits an > important patch on the same date that we need to package. In the *rare* case of an upstream commit at the same date, a suffix can be used, something like 20240411-2+stable-1. BTW, is the "+stable" really useful in the version string? Such information could be given in the Debian changelog (which is already the case) and at some other places. If it is dropped, there's also: 20240411-1 (first version) 20240411a-1 (additional commit on the same date) [...] > To be honest, after writing all this, I'm no longer certain why anyone > would really look at the version number at all for the gnulib Debian > package. A sequentially increasing number is sufficient for packaging > reasons: if anyone really wants to know what git commits are inside the > package, just read the source code in the package to find out. 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. Regards, -- 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)
