From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Liviu Ionescu <ilg@livius.net>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Paolo Bonzini <pbonzini@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Stefan Hajnoczi <stefanha@redhat.com>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [PATCH] Add --with-branding-prefix and QEMU_BRANDING_PREFIX
Date: Wed, 9 Feb 2022 12:25:55 +0000 [thread overview]
Message-ID: <YgOy04WldttoXLSt@redhat.com> (raw)
In-Reply-To: <BB942F04-BF20-4531-A356-DDF7931B1DEB@livius.net>
On Wed, Feb 09, 2022 at 12:13:02PM +0200, Liviu Ionescu wrote:
>
>
> > On 9 Feb 2022, at 11:57, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> >
> >
> > Is the existing ./configure --with-pkgversion= option not enough?
>
> My understanding of --with-pkgversion=, based on the fact that in QEMU this string is appended to the version, was that it is a suffix that describes a specific version.
>
> Most GNU tools, including GCC, binutils, etc, use a similar option, but the string is prepended to the greeting message.
>
> In my use case, --with-branding-prefix does the same, QEMU presents itself with:
>
> .../xpack-qemu-arm-6.2.0-1/bin/qemu-system-arm --version
> xPack QEMU emulator version 6.2.0 (v6.2.0-1-xpack-arm)
> Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
>
> All other binary xPacks (https://github.com/xpack-dev-tools/) do the same.
>
> In my opinion, a prefix is preferred, and is consistent with the GNU behaviour.
Being consistent with GNU doesn't add any functional benefit
over what we already provided, so isn't a compelling justification
IMHO.
> Anyway, having both does not break any backward compatibility and
> does not add any significant overhead/complexity.
Changing the name of the program printed by adding a prefix certainly
could cause compatibility failures. I would not be surprised to see
something looking at the --version output programatically and getting
tripped up by having a arbitrary string prefix.
If there are multiple functionally equivalent ways to achieve the same
goal, it is preferrable to pick one, rather than try to implement all
of them.
Given that we already have --with-pkgversion which satisfies the use
case, I don't see a compelling reason to add a new option.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2022-02-09 12:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-20 11:35 [PATCH] Add --with-branding-prefix and QEMU_BRANDING_PREFIX Liviu Ionescu
2022-01-20 12:05 ` Liviu Ionescu
2022-01-27 12:23 ` Liviu Ionescu
2022-02-08 19:34 ` Liviu Ionescu
2022-02-08 19:58 ` Peter Maydell
2022-02-08 20:39 ` Liviu Ionescu
2022-02-09 9:57 ` Stefan Hajnoczi
2022-02-09 10:13 ` Liviu Ionescu
2022-02-09 11:30 ` Peter Maydell
2022-02-09 12:09 ` Liviu Ionescu
2022-02-09 12:25 ` Daniel P. Berrangé [this message]
2022-02-14 11:54 ` Liviu Ionescu
2022-02-14 12:06 ` Peter Maydell
2022-02-14 12:18 ` Liviu Ionescu
2022-02-14 12:28 ` Daniel P. Berrangé
2022-02-14 13:05 ` Liviu Ionescu
2022-02-14 13:07 ` Daniel P. Berrangé
2022-02-14 13:08 ` Peter Maydell
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=YgOy04WldttoXLSt@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=ilg@livius.net \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/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 NNTP newsgroup(s).