Re: [Buildroot] [PATCH] package/bluez5_utils: expose more disable options

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Thomas, All,

On 2021-07-26 23:07 +0200, Thomas Petazzoni spake thusly:
> On Mon, 26 Jul 2021 22:12:42 +0200
> Michael Nosthoff via buildroot <buildroot@busybox.net> wrote:
> > BlueZ builds a lot of Classic BT profiles by default but allows
> > to disable them. This is especially handy when only BLE is needed
> > and enabled in the kernel.
> > 
> > Otherwise this yields warnings like this on bootup:
> > 
> >  profiles/network/bnep.c:bnep_init() kernel lacks bnep-protocol support
> >  src/plugin.c:plugin_init() System does not support network plugin
> > 
> > Also it allows to disable btmon which should not be needed on
> > production systems and is ~800KB in size.
> > 
> > Expose those options but default to 'y' to no break existing
> > configurations.
> > 
> > Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
> > ---
> >  package/bluez5_utils/Config.in       | 36 ++++++++++++++++++++++++
> >  package/bluez5_utils/bluez5_utils.mk | 41 ++++++++++++++++++++++++++++
> >  2 files changed, 77 insertions(+)
> 
> Applied to master, thanks.
> 
> Arnout, Peter, Yann: in order to preserve backward compatibility,
> Michael has created those new options with a "default y". However,
> while it keeps backward compatibility, it also means that all new users
> will get a more bloated bluez_utils installation than is probably
> necessary. Should we break our backward compatibility rule here and
> drop the "default y" on those new options ?

My opinion is to just drop the 'default y', yes.

We always say that this backward compatibility is being nice to users.
But users who upgrade *must* pay attention to what they do, and I am of
the opinion that this should not be made too easy. Easy enough, yes; too
easy, no.

There are so many things that have to be checked anyway, that we can not
provide for. For example, if the licensing terms of a package changed,
we have no way to propagate that info to the user. Yes, we provide them
with the new terms, but we are not telling them they changed.

Also, the "core" settings, like optimisation, hardening, et al. did
change, but we don't tell users; they have to verify that by themselves.

And when a package brings in a new dependency, we don't tell them
either; they just get that new library that maybe they previously were
fine not having, while now they no longer have the choice...

And changes to the package options are most probably the easiest to
discover: a config that used to build no longer builds because of a
library that is now optionally built, or does not run as expected
because a program is now missing...

And in three years time, we will have a set of Config.in files crippled
because of the excuse that some user rarely upgrade and we just want to
support them... No, thanks. ;-)

That's the same for legacy: how much sensible is it for people to
upgrade in one big leap from a more than 5-year old version to the
latest one? That's is going to be so disruptive that legacy is the
least of the annoyance they will have to face... Upgrading should be
done in small leaps. Even upgrading from one LTS to the next is just a
daunting task... For example, I always upgrade to each intermediate
release and, at the very least, review the configuraton there, resorting
to actual builds and full-CI tests to double check the new version did
not break anything (it always do break some thing or some other)...

For legacy, we do have a central location, so it gets easy to remove
after a while, while for the 'default y', they are scattered everywhere
around the code that it will be impossible to track down...

And then, when we eventually decide to remove them, we won't be able to
do so anyway, because of the excude that existing defconfig files would
now break... :-/

Enough of my ranting, then: "say no to default y". ;-]

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot