On Wed, Feb 05, 2020 at 08:13:19PM +0100, Philippe Mathieu-Daudé wrote: > On 2/5/20 6:51 PM, Daniel P. Berrangé wrote: > > On Wed, Feb 05, 2020 at 06:40:31PM +0100, Aleksandar Markovic wrote: > >> On Sat, Feb 1, 2020 at 7:53 PM Philippe Mathieu-Daudé <f4bug@xxxxxxxxx> wrote: > >>> > >>>>>> @@ -1151,10 +1150,6 @@ for opt do > >>>>>> ;; > >>>>>> --enable-brlapi) brlapi="yes" > >>>>>> ;; > >>>>>> - --disable-bluez) bluez="no" > >>>>>> - ;; > >>>>>> - --enable-bluez) bluez="yes" > >>>>>> - ;; > >>>>> > >>>>> Now than I'm bisecting over this commit, I realize removing this > >>>>> option was not a good idea, we should have done like commit > >>>>> cb6414dfec8 or 315d3184525: > >>>>> > >>>>> @@ -886,10 +885,6 @@ for opt do > >>>>> - --disable-uuid) uuid="no" > >>>>> - ;; > >>>>> - --enable-uuid) uuid="yes" > >>>>> - ;; > >>>>> ... > >>>>> + --enable-uuid|--disable-uuid) > >>>>> + echo "$0: $opt is obsolete, UUID support is always built" >&2 > >>>>> + ;; > >>>> > >>>> Looks trivial ... so if it bugs you, just send a patch? > >>> > >>> I thought about it but this won't fix much, it is too late now. > >>> > >>> I simply wanted to share this bugged me so we try to avoid doing the > >>> same mistake again. > >>> > >> > >> I vote for addition of a change similar to what Philippe described. > >> > >> Furthermore, it looks to me the correct way would be to now do full > >> deprecation of --enable-bluez and --disable-bluez. This means adding > >> this to documentation (not related to bluetooth devices support), not > >> only a change in "configure". This also means that only after two next > >> full cycles these options could be removed. > >> > >> True, this could have been done together with bluetooth devices > >> support deprecation (and in that case we could have deleted these > >> options right away), but it wasn't. Users don't have a crystal ball to > >> know that we assumed that --enable-bluez and --disable-bluez were part > >> of bluetooth devices support, and could rightfully complain about an > >> abrupt elimination of a compile time option. > > > > The deprecation policy is primarily intended for notifying of changes > > to QEMU's stable interfaces ( CLI, HMP, QMP) which affect behaviour > > and usage of QEMU at runtime & are liable to break apps managing > > QEMU. > > > > Changes to build time options have no strong reason to be subjected to > > the deprecation process. If we remove an option at build time the effect > > is noticed immediately and the solution is straightforward (stop passing > > the option). We have added / removed configure options at will with little > > negative feedback historically. We'll have far biggest changes coming to > > the build system in future too, with the introduction of meson. > > I understand your point when looking forward (when distribution upgrade, > it is easy to adapt). > However this is still an issue when looking backward when running > bisection to find regressions. That's only a problem if you were actively setting this particular command line argument. Most developers are just fine with configure auto-detecting stuff. The only time I've ever needed to try to explicitly disable this is in downstream RHEL branches of QEMU 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 :|
