[PATCH for-5.0 3/4] Remove the core bluetooth code
Daniel P. Berrangé
berrange at redhat.com
Thu Feb 6 09:56:01 UTC 2020
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 :|
More information about the libvir-list
mailing list