[PATCH for-5.0 3/4] Remove the core bluetooth code
Thomas Huth
thuth at redhat.com
Wed Feb 5 17:46:24 UTC 2020
On 05/02/2020 18.40, Aleksandar Markovic wrote:
> On Sat, Feb 1, 2020 at 7:53 PM Philippe Mathieu-Daudé <f4bug at amsat.org> wrote:
>>
>> On Sat, Feb 1, 2020 at 7:51 PM Thomas Huth <thuth at redhat.com> wrote:
>>> On 01/02/2020 17.09, Philippe Mathieu-Daudé wrote:
[...]
>>>>> index 6099be1d84..ecce4ada2d 100755
>>>>> --- a/configure
>>>>> +++ b/configure
>>>>> @@ -349,7 +349,6 @@ unset target_list_exclude
>>>>> # Distributions want to ensure that several features are compiled in, and it
>>>>> # is impossible without a --enable-foo that exits if a feature is not found.
>>>>>
>>>>> -bluez=""
>>>>> brlapi=""
>>>>> curl=""
>>>>> curses=""
>>>>> @@ -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.
Feel free to send a patch if it bugs you.
> 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.
I disagree. If you don't know that "bluez" is about bluetooth, then you
should likely not use these options anyway.
Thomas
More information about the libvir-list
mailing list