Simon Josefsson wrote:
> To me, the best solution appears to be to not bother with any *-dirty or
> *-modified keywords (since they convey too little information to be
> useful), and instead have all tools support the 'version-etc' gnulib
> module, and in the Debian (etc) packaging set these parameters
>
> --with-packager=Debian \
> --with-packager-version=$(DEB_VERSION) \
> --with-packager-bug-reports=https://bugs.debian.org/
>
> which results in --version outputs like this:
>
> jas@kaka:~$ /usr/bin/gsasl --version | head -2
> gsasl (GNU SASL) 1.10.0
> Packaged by Debian (1.10.0-5)
> jas@kaka:~$ /usr/bin/idn2 --version | head -2
> idn2 (Libidn2) 2.3.2
> Packaged by Debian (2.3.2-2build1)
> jas@kaka:~$
>
> I believe this approach achives 1) declare what upstream version the
> tool you are running is based on to indicate a possibly patched variant,
> and 2) avoid needless version comparison failures due to '9.1' vs
> '9.1-dirty' when built from patched sources from a git repository.
I definitely agree that the 'version-etc' module is useful for distros
that like to patch most packages (such as Debian); maybe less so for
distros which mostly avoid patching (such as Guix).
As a step to further its adoption, can someone please document the
modules
version-etc
version-etc-fsf
argp-version-etc
in the Gnulib manual? (Not always me :) Simon? Collin?)
Then, it is interesting to note that
* For coreutils programs, "<prog> --help" does not has a "Report bugs..."
output section, because coreutils does not use the
emit_bug_reporting_address function. (Why?)
* For the gettext programs, "<prog> --help" prints
Report bugs in the bug tracker at
<https://savannah.gnu.org/projects/gettext>
or by email to <[email protected]>.
but that form is not foreseen by emit_bug_reporting_address.
Bruno
