From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 9145439960FD for ; Thu, 17 Nov 2022 15:49:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9145439960FD Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668700161; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EVLMdjrifcWh8ht+aA5aAkwWMW/nbN9AvuYLR49UrYM=; b=duJzMKp4uLaJv23F+v7a6ah6XZyt16Egc+uAoFzrimq517Acq1Z6Uyczu7pf/kCa5pLOKz NPZhBP3yAbPYbGpVY4LQ6H6A0d6FQ6/30OjekiAO64MDIrNrNnUbEPw4CRaz76m1sxECSV XUw2sRv/vPje5BTsbjpIQunoXGTaGDY= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-640-ebSablzbMl6IRBlZuUS18g-1; Thu, 17 Nov 2022 10:49:20 -0500 X-MC-Unique: ebSablzbMl6IRBlZuUS18g-1 Received: by mail-wr1-f71.google.com with SMTP id s11-20020adfbc0b000000b0023659af24a8so856414wrg.14 for ; Thu, 17 Nov 2022 07:49:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EVLMdjrifcWh8ht+aA5aAkwWMW/nbN9AvuYLR49UrYM=; b=kvSjWCB5Q2Erb78KzE3Iom1Tci0NkemWISy5+S7QnjVt8WT1H8qz/lqbzAziGT4Aq7 fXogwLq7B7ksVF19PJExJFllWP68ijhA9l12/QYJut+5Sf3m/TpTA1voiK1erkT+gNK0 PuGRLo5EqjjB+hHOXmxv+ncQiJx+TtpplFUxGGcq9w8JqdQ3vXSBI02WKpYa4AtKfkHx kBHY6ZSrn52V7dazOXUgSO8ojQ/opMpRwaSA+2sqrlx/pB+In6mSodSztK+wa6s9Kvg8 Y1u73dBnFJC2pfE4vCK6ZZhf82GOpnTDy2LU0PNN1Vn/2jXEjtP3c2GKq4v1HwVsVeiq 4tog== X-Gm-Message-State: ANoB5pl+Mqi2LxP61rfYy1BcNZDJ/gArSnEus1PZ3kosOLTbkUsIBR/Z 5Lwu8Q1RKmqQgY1qkFbirihh5JOfcpq5tpK04EZD3y+EbUEAX50KgO/Y1XTd8B6a045SRlxWM2s tO+0mj0yjGLghKnH2x6EUWw== X-Received: by 2002:a05:600c:4920:b0:3cf:8b23:549c with SMTP id f32-20020a05600c492000b003cf8b23549cmr2007333wmp.174.1668700158710; Thu, 17 Nov 2022 07:49:18 -0800 (PST) X-Google-Smtp-Source: AA0mqf67qUR8FbCS1OxNGxos+ZWYuuSkQcO7x8gUo2ZOr5WrQwSlh2qZdFJpRWggmxdj1otcyoiwuQ== X-Received: by 2002:a05:600c:4920:b0:3cf:8b23:549c with SMTP id f32-20020a05600c492000b003cf8b23549cmr2007317wmp.174.1668700158303; Thu, 17 Nov 2022 07:49:18 -0800 (PST) Received: from localhost ([31.111.84.238]) by smtp.gmail.com with ESMTPSA id v10-20020adfe28a000000b0023647841c5bsm1254431wri.60.2022.11.17.07.49.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Nov 2022 07:49:17 -0800 (PST) From: Andrew Burgess To: Mike Frysinger Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] gdb: new --with-pkgversion-suffix configure option In-Reply-To: References: <86a03c4f56f167a7c08ce40200425d92a2ac39e8.1668165880.git.aburgess@redhat.com> Date: Thu, 17 Nov 2022 15:49:16 +0000 Message-ID: <87k03t8ttv.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Mike Frysinger writes: > 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. I guess you mean the new --with-pkgversion-suffix here? > (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. I disagree with your use of "have" here. I think it's a subtle but important distinction. So long as vendor version numbers are different from upstream version numbers, "we" (the upstream GDB community) can just refer users to their vendors (For issues that are not reproducible in upstream GDB - we are after all a pretty helpful community I think). > users will also do > things like search for "GDB version 13.1.5" and then get confused when no such > release exists. I think my choice of ".5" here as an example was not a good choice. The configure option takes any string and just appends it at the end of the version number. So we could use "-p5", or " patch 5". You talk about this more below and list strings like that as being a better choice than something like ".5". If a vendor chooses to use a particular version number, and that ends up confusing users, then that is unfortunate, but surely that's a vendor issue? > > 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: I'm not sure who you mean by "we" in this sentence. I really don't see the existence of some additional customisation as being a blocker for upstream GDB making whatever releases it wants, so I reject your assertion that having this feature would mean "...we can never release a point version after that...". > 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. I think this is the idea that confuses me the most: by what mechanism do you think vendors would block us making a point release? These vendors are downstream of us, we make a release and they pick that up. Those vendors are free to come to this list and express an opinion, just like anyone else, but at the end of the day, we'll continue to make decisions as a group, in the best interest of GDB, just like we always have. > > 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" As I said above, maybe using ".5" as an example was a poor choice. I could just as easily configure --with-pkgversion-suffix=" patch 5" to get: GNU gdb (GDB) 13.1 patch 5 that's why the new option takes a string, not a version number. And notice, in the example I give, the '.' is included in the configure option, it's not being added within GDB. I'm free at configure time to customise the output how I see fit. > or something like that ? this sounds like a bug in the distro/vendor that > you're working on. I'd disagree with "bug" here, surely it's just a choice that you personally disagree with? I'd like to discuss the benefits and/or drawbacks of the proposal on its technical merits, rather than just dismissing it as a bug. > > 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 That's great. And can continue unchanged if that's your preference. This proposal is about choice, not about trying to force all distros to do things one particular way. Some distros might want the version number to match the version number from the package that was used to install GDB. I don't think either approach is wrong, it's just, right now, one approach is supported in upstream GDB, and one approach is 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. I agree it seems a little weird. But I certainly don't want to get off track looking at that right now. My interest is the other end of the version string. > > 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 ? I was hoping to propose a plan that would allow distros to continue to operate as they currently do, while at the same time offering more flexibility. When I started thinking about this work, I did initially wonder about a totally generic "version format" type idea, e.g. configure with: --with-version-format="GNU gdb {pkgversion} {version_number} patch 5" \ --with-pkgversion="My Distro" which would give: GNU gdb (My Distro) 13.1 patch 5 But could also allow: --with-version-format="GNU gdb (GDB) {version_number}\nVendor: My Distro 13.1 patch 5" \ --with-pkgversion="My Distro" Which would give: GNU gdb (GDB) 13.1 Vendor: My Distro 13.1 patch 5 But I rejected this idea because (a) totally over the top for what I actually wanted (append to the version string), and (b) would allow vendors to easily drop the 'GNU gdb' string, which I didn't think was a good idea, and (c) a vendor might even drop the major version number, which seemed like a bad plan. > > $ gdb --version > GNU gdb (GDB) 12.1 > Vendor: Gentoo 12.1 p3 Personally, not a fan of information duplication like this. > 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. 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 guess by this you mean adding the macro to config/acx.m4? I'm not super keen to rush off to do that right from the start. I'd much rather get something that working (and acceptable) for GDB, and then have folk generalise it if it works. I deliberately picked the --with-pkgversion-suffix name to be consistent with the existing --with-pkgversion option, so if at some future time to macro was moved into acx.m4, the configure interface would remain the same. If I rewrote the proposal, but changed my example from ".5" to " patch 5", it feels like a lot of the issues you raised above would disappear. Would you feel more comfortable with that approach? I think your second concern, about where the autoconf macro lives can be put aside until we reach agreement on the core of the issue. Thanks, Andrew