qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add --with-branding-prefix and QEMU_BRANDING_PREFIX


From: Daniel P . Berrangé
Subject: Re: [PATCH] Add --with-branding-prefix and QEMU_BRANDING_PREFIX
Date: Wed, 9 Feb 2022 12:25:55 +0000
User-agent: Mutt/2.1.5 (2021-12-30)

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 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]