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

[Thomas Huth <thuth@redhat.com>]

On 05/02/2020 18.40, Aleksandar Markovic wrote:
> On Sat, Feb 1, 2020 at 7:53 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>
>> On Sat, Feb 1, 2020 at 7:51 PM Thomas Huth <thuth@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