[PATCH for-5.0 3/4] Remove the core bluetooth code

[Daniel P. Berrangé]

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 at amsat.org> 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 :|