public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Sam James <sam@gentoo.org>
To: Mike Frysinger <vapier@gentoo.org>
Cc: Andrew Burgess <aburgess@redhat.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb: new --with-pkgversion-suffix configure option
Date: Thu, 17 Nov 2022 16:26:08 +0000	[thread overview]
Message-ID: <FC46D778-B1FA-4F10-830D-D104BDA45853@gentoo.org> (raw)
In-Reply-To: <Y3UWu6BPdAFI+50y@vapier>

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



> On 16 Nov 2022, at 16:58, Mike Frysinger via Gdb-patches <gdb-patches@sourceware.org> wrote:
> 
> 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 ?

I feel the same. The approach we use in Gentoo seems to work well enough
And diverting from the standard autotools way of doing this feels unfortunate.

It's really nice to be able to bang these options in to GNU projects and
have it just work.

I agree the suggested output change might be a bit neater though.

When I first saw the patch, I assumed that someone had just missed
the existing options existed.

Best,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

      parent reply	other threads:[~2022-11-17 16:26 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
2022-11-17 15:49   ` Andrew Burgess
2022-11-17 16:26   ` Sam James [this message]

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=FC46D778-B1FA-4F10-830D-D104BDA45853@gentoo.org \
    --to=sam@gentoo.org \
    --cc=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=vapier@gentoo.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).