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;
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: A package version "20240411~b57dd0d+stable202401.20240408~aa0aa87" means that the gnulib git clone had the latest commit on "master" dated "20240411" with revision "b57dd0d" and the "stable-202401" branch had a commit dated "20240408" with revision "aa0aa87". The files in /usr/share/gnulib correspond to files on the "stable-202401" branch with revision "aa0aa87", except for /usr/share/gnulib/gnulib.bundle which is a git bundle containing both master and stable branches up until "b57dd0d" (master) and "aa0aa87" (stable-202401) respectively. This approach enable /usr/share/gnulib to be an unpacked stable gnulib release, but the /usr/share/gnulib/gnulib.bundle (which is more likely to be used by other packages for bootstrapping) can contain newer commits too. So there really are two upstreams versions involved, and upstream neither tag nor release tarballs, so timestamps, branch names and git commits are the only identifiers that we have available: 0~a57dd0d~stable-202401~ba0aa87 It could be that we will have these two versions at some point, maybe one in unstable and one in experimental: 20250411~a57dd0d+stable202501.20250408~ba0aa87 20250411~a57dd0d+stable202407.20250308~c928adb That correspond to the same master branch but different stable branches. We could also have differences like this, showing updated commits on the same stable branch: 20250411~a57dd0d+stable202501.20250408~ba0aa87 20250411~a57dd0d+stable202501.20250308~c928adb Upstream maintains multiple stable branches in parallel. We can have uploads for different master commits but same stable branch, consider if a security fix was applied to a stable branch at some point: 20250411~8585cab+stable202501.20250408~ba0aa87 20250411~abc4818+stable202501.20250408~abc4874 or even: 20250411~8585cab+stable202501.20250408~ba0aa87 20250311~abc4818+stable202501.20250408~ba0aa87 To be able to identify the upstream version, we need the information of the commit id on the master branch together with which stable branch was used and which commit on the stable branch. 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. 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. 20240411~a57dd0d-1 - this makes the git commit identifiable, but loses information about which stable branch was used. Maybe the stable branch version is more important than the master branch release date? 20240411+stable2401~a47dd0d-1 - this adds the release branch used, and has git commit id corresponding to git master. May lead to version conflicts if multiple releases are needed on the same date. I guess you can come up with some more variations that for better or worse make some sense. 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. So maybe just fall back to what 'uscan' suggests: 20240418~0a85f70-1. Or 20240418+stable-1 like we had before, although I'm not really sure if the '+stable' helps anyone, and it is a bit confusing if the date refers to the timestamp on the stable or master branch. > I'm wondering whether it is intended or is due to a bug in a script > (the "Fix gnulib-tool --version" seems to have done nothing > significant). The current version scheme is intentional, but I'm open to changing it. That was a unrelated fix: before 'gnulib-tool --version' tried to parse /usr/share/doc/gnulib/NEWS.stable.gz, which doesn't exist, so you got an error message and the printed version string became garbled. /Simon
signature.asc
Description: PGP signature
