From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 83FF1395BC51 for ; Wed, 16 Nov 2022 16:58:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 83FF1395BC51 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org Received: by smtp.gentoo.org (Postfix, from userid 559) id 455FD340E6E; Wed, 16 Nov 2022 16:58:37 +0000 (UTC) Date: Wed, 16 Nov 2022 23:58:35 +0700 From: Mike Frysinger To: Andrew Burgess Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] gdb: new --with-pkgversion-suffix configure option Message-ID: Mail-Followup-To: Andrew Burgess , gdb-patches@sourceware.org References: <86a03c4f56f167a7c08ce40200425d92a2ac39e8.1668165880.git.aburgess@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="B4w7WsJYMUC3aDmp" Content-Disposition: inline In-Reply-To: <86a03c4f56f167a7c08ce40200425d92a2ac39e8.1668165880.git.aburgess@redhat.com> X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --B4w7WsJYMUC3aDmp Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 11 Nov 2022 11:24, Andrew Burgess via Gdb-patches wrote: > Once GDB 13.1 is released, then the version string, for a build of GDB > made from the release branch should look like this: >=20 > $ gdb --version > GNU gdb (GDB) 13.1 >=20 > We provide a configure option, --with-pkgversion, which allows control > over the 'GDB' string within '(GDB) ', and so, if we configure like > this: >=20 > $ ../src/configure --with-pkgversion=3D"My Distro" >=20 > then the final GDB's version string would look like this: >=20 > $ gdb --version > GNU gdb (My Distro) 13.1 >=20 > It is not unreasonable to think that somebody building a distribution > specific version of GDB like this might want to also augment the > version number (13.1) in order to indicate a local patch level. >=20 > Now, the existing configure option, --with-pkgversion, clearly seems > to indicate that the package specific version number should be > included here, however, I don't find this result satisfactory. >=20 > Here are some possibilities. I could include the full version number, > including my local patch number, like this: >=20 > GNU gdb (My Distro 13.1.5) 13.1 >=20 > I don't like this because of the duplication. I could drop the > upstream version number, like this: >=20 > GNU gdb (My Distro 5) 13.1 >=20 > But I don't like this because it (IMHO) can lead to confusion, is this > GDB version 5? Version 13.1? I think this can potentially cause > confusion for a user. >=20 > I propose that a far better solution is to add a new configure option > that will allow me to attach additional content at the end of the > version string, like this: >=20 > GNU gdb (My Distro) 13.1.5 i strongly dislike this proposal because it's smooshing distro versions and official versions with no clear separation at all. this is bad for us, bad for our users, and imo bad for even the distros/vendors. if --with-pkgversion=3D isn't specified, the users will see the bare versio= n only. (yes, i'm aware people can patch the source to display whatever they want, = but that doesn't mean we have to encourage or make it easy to do) even if it is specified, users will say things like "i'm using GDB 13.1.5", and then we'll have to figure out whose "13.1.5" that is. users will also = do things like search for "GDB version 13.1.5" and then get confused when no s= uch release exists. it also means once we release a GDB version X, we can never release a point version after that (e.g. X.Y). which is what these docs, albeit perhaps outdated, explain: https://sourceware.org/gdb/wiki/Internals%20Versions i'm aware that currently we've moved to X.Y and don't seem to ever plan on doing plain X or X.Y.Z, but that doesn't mean we should cede the entire future to random vendors. backing up a bit, the example you provided is: > GNU gdb (My Distro 13.1.5) 13.1 first off, i don't see a problem with the duplication, but that's me. second, it sounds like your distro is claiming version numbers it shouldn't= ? why are you calling it version "13.1.5" instead of "13.1 patch 5" or "13.1-= 5" or something like that ? this sounds like a bug in the distro/vendor that you're working on. in Gentoo we use: > GNU gdb (Gentoo 12.1 p3) 12.1 > GNU gdb (Gentoo 12.1 vanilla) 12.1 to make it very clear to everyone involved: (1) it's a Gentoo build (2) what our upstream base version is (3) what the Gentoo packaging version is (4) how we've patched it, or not personally i've never found the "(GDB)" to be useful information. seems li= ke we could do away with it entirely ? i'll admit i haven't looked at the his= tory of it at all though. if we want to avoid changing existing behavior/format in the --version stri= ngs, maybe we should have a new configure option that inserts a new line so it's very clear what's going on ? $ gdb --version GNU gdb (GDB) 12.1 Vendor: Gentoo 12.1 p3 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. > --- /dev/null > +++ b/gdbsupport/pkgversion-suffix.m4 > + > +dnl Add support for the --with-pkgversion-suffix configure option. Allo= ws > +dnl the user to specify a string that is appended to the version number. > +AC_DEFUN([GDB_PKGVERSION_SUFFIX],[ > + AC_ARG_WITH(pkgversion-suffix, > + AS_HELP_STRING([--with-pkgversion-suffix=3DSTRING], > + [Append STRING to the end of the version number]), i really dislike how this is made into a gdb-only thing. the existing opti= ons --with-pkgversion=3D & --with-bugurl=3D are pretty standard across the GNU = toolchain project space and are extremely helpful to keep consistent. can we please = look for a solution that maintains that consistency ? -mike --B4w7WsJYMUC3aDmp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmN1FrsACgkQQWM7n+g3 9YE/1RAAyKizedmoOSXEIPPwuIwNd6aPgpi4NU/QAoxdWalVixc1SbhkX2v891Q+ DA2oPa1JhQn9rldN/MP4s8j7Ozzz1Jutnmhj+G1RRlAlmSbAdZnitC6sCJhXtiT+ yVUPwqLJE2bKbcZAS3kXdos6+S/c4HIBLhW2WmNIeU9xgVuTtpq0g3/YPTK7NcPf bMZ8drh4ZBnBhqC/K4ZcQH9UzY9GTwLCwmTUXHRW0xFkOrxeCjCSMlnmIi3ZCv8x JgU+nP6bJMsOfy32/USS/X6SfCSNr0L/l2JwgLHao4pV6j0ivwtMskMWv1A6bvY1 48NC+EZUJSeqwzoB/g3CMAXW4oc2EqYo+ti93HM0STvY3c8rC3s/Uwxz1/MyW6L4 njZ8InrX/EUm+Agu7+ZO4bm56O21ZirjLhmz3SUJPKXi8EIHib8Z1YaexMD+UZX9 tDw61SqygjoX1fzG2lxrF7MzFGYIbXvl5TXKkb9Lp1oWQEX9QDSkUfjnUdy04O+K prTRicVkYYQ3tO5H/pSUbVWu4Yaz/HIUfphapFlENa1H/azeEvN/ajKI+S6kSn94 VwxZNoLzo+iiA8fUEpHpy0n8Tf40qup3Va1nfalhNj74TdRKTgz+Tbgn8BCOndyq HSLcBt7h9x89pK4f4ZwgWsOtAAsFkShhDjHUPgW1Z+wjY2RsRkI= =pX67 -----END PGP SIGNATURE----- --B4w7WsJYMUC3aDmp--