From: Michael Stapelberg <email@example.com>
To: Ingo Schwarze <firstname.lastname@example.org>
Subject: Re: [PATCH] Implement -v to display the current version and exit
Date: Tue, 17 Jan 2017 08:28:48 +0100 [thread overview]
Message-ID: <CANnVG6=KSBba4AeJ=4CwvHEuiUSh=7GCa0uqN_9n76DtKiWRaQ@mail.gmail.com> (raw)
On Tue, Jan 17, 2017 at 1:37 AM, Ingo Schwarze <email@example.com> wrote:
> 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
> 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
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.
To unsubscribe send an email to firstname.lastname@example.org
next prev parent reply other threads:[~2017-01-17 7:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-16 8:29 Michael Stapelberg
2017-01-17 0:37 ` Ingo Schwarze
2017-01-17 7:28 ` Michael Stapelberg [this message]
2017-01-17 13:09 ` Ingo Schwarze
2017-01-17 13:22 ` Michael Stapelberg
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).