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

On Sat, Feb 1, 2020 at 7:53 PM Philippe Mathieu-Daudé <f4bug(a)amsat.org&gt; 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.