[OE-core] [PATCH] connman: add alias for connman
zhenbo
zhenbo.gao at windriver.com
Wed May 25 09:41:50 UTC 2016
On 2016年05月25日 16:05, Richard Purdie wrote:
> On Wed, 2016-05-25 at 15:11 +0800, Zhenbo Gao wrote:
>> connman get conflicts with networkmanager when building
>> the project.
>>
>> here introduce alias virtual/networkmanager for these
>> two recipes, so setting PREFERRED_PROVIDER to the proper
>> one can solve the conflicts.
>>
>> this patch is for connman recipe.
> We do not use the virtual/* namespace in package dependencies, only in
> the build time DEPENDS/PROVIDES space. This is because there is no way
> to indicate how the package manager should resolve such things amongst
> many other reasons.
Hi Richard & Andreas,
Thanks for replying this mail.
The situation on my side is: if my project include connman and
networkmanager at the same time, the compile step will fail:
...
Computing transaction...error: Can't install
xfce4-power-manager-1.4.4-r0.0 at corei7_64: unable to install provider for
networkmanager:
error: networkmanager-1.0.4-r0.0 at corei7_64 conflicts with
connman-1.30-r0.0 at corei7_64
...
The dependence relationship is:
xfce4-power-manager --> networkmanager
packagegroup-self-hosted --> connman
Anyway, the patch is not suitable, Koen Kooi(koen at dominion.thruhere.net)
has suggested me to fix packagegroup-self-hosted to not specify a
connection manager.
When i am trying to fix my issue, i was wondering why self-hosted needs
connman ? if self-hosted really don't need connman, the way provided by
koen is the best solution for this issue.
The draft patch looks like:
---
--- a/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb
@@ -28,8 +28,6 @@ RDEPENDS_packagegroup-self-hosted = "\
"
RDEPENDS_packagegroup-self-hosted-host-tools = "\
- connman \
- connman-plugin-ethernet \
dhcp-client \
e2fsprogs \
e2fsprogs-e2fsck \
What do you think? is that ok? if so, i will send an official patch for it.
Thanks,
Zhenbo
> Cheers,
>
> Richard
>
More information about the Openembedded-core
mailing list