Re: [PATCH] Implement -v to display the current version and exit

[Michael Stapelberg <stapelberg@debian.org>]

On Tue, Jan 17, 2017 at 1:37 AM, Ingo Schwarze <schwarze@usta.de> wrote:
> Hi,
>
> Michael Stapelberg wrote on Mon, Jan 16, 2017 at 09:29:07AM +0100:
>
>> When using mandoc's output in other services (e.g. a web man viewer),
>> it would be beneficial to display the version of mandoc that is in
>> use.
>
> Why?  In particular in a web viewer, you would end up displaying
> that to end users.  They really shouldn't care.

End users might want to reproduce a rendering issue before reporting a
bug. For this use-case, it seems useful to know the version which was
used to generate the page.

>
>> Currently, one cannot determine mandoc's version in a package
>> management-indepent way.
>
> Exactly, and that's a feature.  Version numbers contained in binaries
> are very harmful.
>
> Years ago, this option existed.  I got so fed up with it that i
> deleted it.  Before, many bug reports were unusable because
> people simply said "i'm using mandoc-1.10.5" and didn't bother
> mentioning how it was built and packaged, or whether it was -current
> or -release.
>
> Once the version-option was gone, that problem completely went away
> and people started reporting properly, like "i installed mandoc
> from pkgsrc on FreeBSD 9, and ..." or "I compiled mandoc from
> CVS HEAD as of (date) on Solaris 11, and ..."

In my projects, when I was faced with this problem, I went exactly the
other route: I find “latest version that’s in FreeBSD 9” way to
imprecise, and just have my build system embed the git version number.
This works really well for me, but distributions tend to not patch my
projects.

I still think it’s valuable to have the upstream version number
available somehow. If you don’t want it to be considered as the
primary source of version information, that’s fine. Would you be okay
with making it available under a hard-to-discover flag name, e.g.
--upstream-version, accompanied by a message stating that users should
provide their package manager’s version when reporting bugs instead?

>
>> Please consider merging the attached patch. Thanks!
>
> No, i don't want that.
>
> If you absolutely need that for debian, consider making it a
> debian-local patch, but please make sure that the following is
> contained in the response printed:
>
>  (1) the substring "debian"
>  (2) if the package is OS-version-dependent, the complete version
>      of the operating system the binary can run on
>  (3) the name of the package manager that created the package
>      containing the binary
>  (4) the version number that package manager assigned to the
>      package, including OS-local patch levels
>
> Including the upstream release number is not important - but
> it will likely happen anyway because it's probably part of item (4).
>
>
> I cannot do that upstream because the essential information to
> print is package-manager-dependent, and by definition, the
> upstream build system cannot know anything about that.
>
> But anyway, keeping track of which versions of software you have
> installed is the task of the package manager in the first place,
> and not the task of individual programs.
>
> Oh, by the way, why can't you get the information you want from
> the package manager instead of from mandoc?  If you can run
>
>   mandoc -V
>
> i guess you can run
>
>   dpkg-query -l mandoc
>
> with the proper options just as well?

I could, but this would make my program non-portable. Worse, when
users put a different version of mandoc into their $PATH, the reported
version will be misleading.

-- 
Best regards,
Michael
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv