[OE-core] [PATCH 1/5] connman: Upgrade to version 0.75

[Anders Darander]

On Tue, Jun 21, 2011 at 11:54, Koen Kooi <koen at dominion.thruhere.net> wrote:
>
> Op 21 jun 2011, om 11:34 heeft Anders Darander het volgende geschreven:
>
>> On Tue, Jun 21, 2011 at 11:12, Phil Blundell <pb at pbcl.net> wrote:
>>> On Tue, 2011-06-21 at 16:08 +0800, Dongxiao Xu wrote:
>>>> -DEPENDS  = "libgdbus dbus glib-2.0 hal iptables"
>>>> -RDEPENDS_${PN} = "wpa-supplicant resolvconf"
>>>> +DEPENDS  = "libgdbus dbus glib-2.0 hal iptables ofono wpa-supplicant resolvconf bluez4"
>>>
>>> What does the dependency stack for ofono look like?  If it's non-trivial
>>> then I am not sure it is a good idea to add ofono to DEPENDS
>>> unconditionally.
>>
>> Although Koen showed that the dependcies were quite trivial, I'd
>> prefer to not build ofono if it is possible.
>>
>>> Ditto bluez4, I don't think that should be in there unless
>>> DISTRO_FEATURES requested it.
>>
>> Yes, I certainly agree with you on bluez4. If we don't have bluetooth
>> enabled for our machine/distro, I definitely prefere to not build it.
>>
>> To me it's not only about the risk that we increase the rootfs, but
>> also about build-times. Even if we have quite fast machines today, it
>> is a waste of CPU cycles to build lots of SW that aren't going to be
>> used...
>>
>> Adding a dependency etc is easily done in a bbappen-file, which makes
>> the reversed desire quite easy. I'm not sure if there is an easy way
>> of removing item from e.g. DEPENDS and EXTRA_OECONF etc.
>
> I'd trade extra build time over not having to use bbappends anytime. Especially where upstream has proper plugin support like connman.

In cases like connman (with proper plugin-support, and a good
packaging), yes, then it is only about build time. And sure, in some
cases I completely agree with you.

However, occasionally when building a really tiny image adding a small
package could result in a complete build of X and lots of other stuff.
In such cases it's not always that funny. (Sorry, it was a long time
ago on .dev that this happened, so I don't remember what package it
was). Apart from these kind of situations, it's normally not a big
problem, unless you're in a development stage where you need frequent
clean rebuilds...

(Another drawback, although it is really only on the first build, is
that building lots of unnecessary packages increases the risk of
build/fetch problems.)

Currently I can't access cgit.openembedded.org (probably the local
network), so I can't check it. But isn't e.g. bluetooth found
somewhere in either DISTRO_FEATURES or MACHINE_FEATURES? If so, bluez4
and configure options should probably be set conditionally.

/Anders