All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Nosthoff via buildroot <buildroot@busybox.net>
To: Arnout Vandecappelle <arnout@mind.be>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: buildroot@buildroot.org,
	"Yann E. MORIN" <yann.morin.1998@free.fr>,
	Marcin Bis <marcin@bis.org.pl>
Subject: Re: [Buildroot] [PATCH] package/bluez5_utils: expose more disable options
Date: Tue, 27 Jul 2021 22:19:16 +0200	[thread overview]
Message-ID: <1852b497-3fb1-5fca-b01e-33e1f51d9221@heine.tech> (raw)
In-Reply-To: <58f8221d-3cd0-7742-b1cc-30f7d94ba88f@mind.be>

Hi,

On 27.07.21 21:53, Arnout Vandecappelle wrote:
> On 26/07/2021 23:07, Thomas Petazzoni wrote:
>> 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 ?

If we go for a compatibility break here I would then also submit a patch 
to make
"--disable-tools" configurable and default to no. Those tools are 
usually not
required when using d-bus and/or bluetoothctl and add up to 1-2MB.

I was hesitant on this one because the relation with 
--disable-deprecated, which
buildroot already exposes, is a bit weird but I think i figured it out.

>   I know from experience that that's the kind of tricky changes that can make it
> annoying to update Buildroot.
>
>   Assuming you select bluez5_utils from menuconfig, having a default y is not
> much of a problem in practice. However, bluez5_utils is also selected
> automatically by a couple of packages [*] - in that case, the user doesn't see
> the suboptions so isn't aware that they can disable them.
>
>   So yes, there are good reasons to prefer default n. But then I think we should
> think of a way to smoothen things for people who want to update buildroot. Here
> are a few ideas:
>
> - Just mention it in CHANGES.
 From a user perspective I think this should mention this, even if we go 
with the migrating.txt
or another approach. Because this is where I look on upgrading before 
trying to build.

> [*] BTW, did someone check if those packages that select bluez5_utils now should
> be updated to select the appropriate plugin? Probably not - I imagine cwiid (for
> the wiimote) for example needs the HID plugin, and the gstreamer plugin needs
> A2DP and/or AVDP. Runtime dependencies, of course, so we'll never know until
> someone actually complains about it.

I have some spare time in the next days. I'll check the dependencies 
where possible.

Regards,
Michael

_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

  reply	other threads:[~2021-07-27 20:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-26 20:12 [Buildroot] [PATCH] package/bluez5_utils: expose more disable options Michael Nosthoff via buildroot
2021-07-26 21:07 ` Thomas Petazzoni
2021-07-27 19:53   ` Arnout Vandecappelle
2021-07-27 20:19     ` Michael Nosthoff via buildroot [this message]
2021-07-28 17:00   ` Yann E. MORIN

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1852b497-3fb1-5fca-b01e-33e1f51d9221@heine.tech \
    --to=buildroot@busybox.net \
    --cc=arnout@mind.be \
    --cc=buildroot@buildroot.org \
    --cc=buildroot@heine.tech \
    --cc=marcin@bis.org.pl \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=yann.morin.1998@free.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.