[Buildroot] [PATCH] package/bluez-alsa: bump to version 2.0.0

Jörg Krause joerg.krause at embedded.rocks
Wed Oct 16 21:34:25 UTC 2019

Hi Thomas,

On Wed, 2019-10-16 at 21:31 +0200, Thomas Petazzoni wrote:
> Hello,
> On Wed, 16 Oct 2019 11:55:01 +0200
> Jörg Krause <joerg.krause at embedded.rocks> wrote:
> > Add the bluealsa-aplay client application as a config option, as it does
> > not use libglib2 anymore (like the server application bluealsa), but libdbus.
> I am confused by this statement. Did bluealsa-aplay exist before? Why
> was it a problem that it was using libglib2 ?

Sorry for the confusion! Yes, bluealsa-aplay existed before and was
unconditionally built. For client applications (like bluealsa-aplay),
the maintainer switched from libglib2 to libdbus "in order to minimize
library footprint" [1].

> The current bluez-alsa package anyway already selects libglib2, so what
> is the problem ? I am a bit confused.

You're right, bluez-alsa still needs libglibs for its server
application named "bluealsa". In fact, there is no problem with the
dependencies. I thought in might be a good idea to allow not building
bluealsa-aplay, e.g. when using one of the other client applications
like rfcomm.

> > Furthermore, bluealsa can be used without bluealsa-aplay.
> And?

See above.

> >  
> > +	bool "aplay"
> > +	select BR2_PACKAGE_DBUS
> The main BR2_PACKAGE_BLUEZ_ALSA option selects bluez5_utils, which
> already selects dbus. Is that just for correctness that you added the
> select here ?


[1] https://github.com/Arkq/bluez-alsa/commit/5c8dcce999297bfa91345c034de6083773307f5a#diff-69f2fc2be0364f0621a94936a1ecac53


More information about the buildroot mailing list