From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf0-f67.google.com (mail-lf0-f67.google.com [209.85.215.67]) by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id 8ebf364f for ; Tue, 17 Jan 2017 02:29:12 -0500 (EST) Received: by mail-lf0-f67.google.com with SMTP id x1so9664918lff.0 for ; Mon, 16 Jan 2017 23:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=i3wm-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=tJeU3pEnQvaXlOsADBtZSoePjhtAvtiPIv59WQUKp3Q=; b=vVpgSiRgBb2+O7/Zc8yACfJKoYYUSCUsJssbjg7o4DIYwVo74X0ZBkfLhvzjc+zmHQ vnspKR1YJpzirNQ/WEMc3GRKZIf2TO9BF7kmswwQic95Plepj861D9xhqs0+q90I/1Z0 KrgXVHNohFZxAZl+CjxXafg9t3Smr9oGXU8qbhSj0+9rKBIrHJXhS4ufmV2soKx4iSHu V5rAbc1nfrZgBpKtyrShGhynbmE7dHzO5RcwePwADtmzd74sOXEk9vKwkStGjc2nd4z/ TUY6JmDAO5N1sxOkz0TG4IN2CvQ9i8SDqn9vObsmDCPLMRw9S807oEGJi5oM6dAt8GCi +gLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=tJeU3pEnQvaXlOsADBtZSoePjhtAvtiPIv59WQUKp3Q=; b=beCndLzMURbLJD1Anixv8/3A8/Igma+4KG8PWz9oO+J4IRjeLeEVTc1VQ88cklcEmt zgxK8s9eErNfQid0kXiZDlkApymCj64xj0CqglFOtyty089rPlKDLoyVnxUpf2oPNlr0 3NN61T8dsMPvI9MO7sh2M38v2REMPMWom1nL/kTGxyOsaVPvedEcBqURPdEknr4YeO61 gVBIX9osjKw/s/3bVCsj95jIXzks8VX6st+IElrtqv1AeeDn0ZYNVcqhsu4V56QcjvCS DhUCUt7cknFEvxFLttASQyL/tINKDNdK7VC+wPQs4H9bScIl6mQH6CWUK2puc2VPlM34 Uh6Q== X-Gm-Message-State: AIkVDXL9RwqOwNgfFA2RD23J5e+YerkT5eLVhW43bqBPe9VswGpL7KMprBzmMKtS0+NH7OUcXowf1RAPW64C7g== X-Received: by 10.46.76.9 with SMTP id z9mr9825246lja.1.1484638149534; Mon, 16 Jan 2017 23:29:09 -0800 (PST) X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 Sender: michael@i3wm.org Received: by 10.25.216.206 with HTTP; Mon, 16 Jan 2017 23:28:48 -0800 (PST) X-Originating-IP: [2a02:168:4a00:0:225:90ff:fe5d:53a2] In-Reply-To: <20170117003727.GA87474@athene.usta.de> References: <20170117003727.GA87474@athene.usta.de> From: Michael Stapelberg Date: Tue, 17 Jan 2017 08:28:48 +0100 X-Google-Sender-Auth: KiC9fcpIEtBDMngsc5rOIVyPaMs Message-ID: Subject: Re: [PATCH] Implement -v to display the current version and exit To: Ingo Schwarze Cc: tech@mdocml.bsd.lv Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 17, 2017 at 1:37 AM, Ingo Schwarze 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 =E2=80=9Clatest version that=E2=80=99s in FreeBSD 9=E2= =80=9D 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=E2=80=99s valuable to have the upstream version number available somehow. If you don=E2=80=99t want it to be considered as the primary source of version information, that=E2=80=99s fine. Would you be ok= ay 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=E2=80=99s 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. --=20 Best regards, Michael -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv