public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: Andrew Burgess <aburgess@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb: new --with-pkgversion-suffix configure option
Date: Wed, 16 Nov 2022 23:58:35 +0700	[thread overview]
Message-ID: <Y3UWu6BPdAFI+50y@vapier> (raw)
In-Reply-To: <86a03c4f56f167a7c08ce40200425d92a2ac39e8.1668165880.git.aburgess@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 4898 bytes --]

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:
> 
>   $ gdb --version
>   GNU gdb (GDB) 13.1
> 
> We provide a configure option, --with-pkgversion, which allows control
> over the 'GDB' string within '(GDB) ', and so, if we configure like
> this:
> 
>   $ ../src/configure --with-pkgversion="My Distro"
> 
> then the final GDB's version string would look like this:
> 
>   $ gdb --version
>   GNU gdb (My Distro) 13.1
> 
> 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.
> 
> 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.
> 
> Here are some possibilities.  I could include the full version number,
> including my local patch number, like this:
> 
>   GNU gdb (My Distro 13.1.5) 13.1
> 
> I don't like this because of the duplication.  I could drop the
> upstream version number, like this:
> 
>   GNU gdb (My Distro 5) 13.1
> 
> 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.
> 
> 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:
> 
>   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= isn't specified, the users will see the bare version 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 such
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 like
we could do away with it entirely ?  i'll admit i haven't looked at the history
of it at all though.

if we want to avoid changing existing behavior/format in the --version strings,
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 <http://gnu.org/licenses/gpl.html>
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.  Allows
> +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=STRING],
> +                   [Append STRING to the end of the version number]),

i really dislike how this is made into a gdb-only thing.  the existing options
--with-pkgversion= & --with-bugurl= 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2022-11-16 16:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-11 11:24 Andrew Burgess
2022-11-16 16:19 ` Tom Tromey
2022-11-16 16:58 ` Mike Frysinger [this message]
2022-11-17 15:49   ` Andrew Burgess
2022-11-17 16:26   ` Sam James

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y3UWu6BPdAFI+50y@vapier \
    --to=vapier@gentoo.org \
    --cc=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 read-only IMAP folder(s) and NNTP newsgroup(s).