[PATCH for-5.0 3/4] Remove the core bluetooth code
Philippe Mathieu-Daudé
f4bug at amsat.org
Wed Feb 5 19:13:19 UTC 2020
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.
> I don't think we want to constrain & complicate our work in modernizing
> the build system by declaring that any changes to it must go through
> deprecation.
>
> Regards,
> Daniel
>
More information about the libvir-list
mailing list