[OE-core] [PATCH V3 0/2] BlueZ 5 experimental recipes

Iorga, Cristian cristian.iorga at intel.com
Tue Jul 16 14:49:56 UTC 2013


This will happen only when bluez5 will be a replacement for bluez4, which is not the case now, but it will be when everything else is ready for bluez5.

-----Original Message-----
From: Saul Wold [mailto:sgw at linux.intel.com] 
Sent: Tuesday, July 16, 2013 5:48 PM
To: Iorga, Cristian
Cc: Phil Blundell; openembedded-core at lists.openembedded.org
Subject: Re: [OE-core] [PATCH V3 0/2] BlueZ 5 experimental recipes

On 07/16/2013 07:36 AM, Iorga, Cristian wrote:
> " why having it be so is not a very good thing."
>
> Sorry, I did not understood this part.
>
> Judging by my investigation, is RREPLACES needed or not?
>
I believe that RREPLACES is not needed, it could cause problems if a feed builds the bluez5 packages but does not want to use them, without the RREPLACES it requires a conscious effort on the target to get the update.

The upgrade case is exactly why we should not have RREPLACES.

Sau!

> /Cristian
>
> -----Original Message-----
> From: Phil Blundell [mailto:pb at pbcl.net]
> Sent: Tuesday, July 16, 2013 5:34 PM
> To: Iorga, Cristian
> Cc: openembedded-core at lists.openembedded.org
> Subject: Re: [OE-core] [PATCH V3 0/2] BlueZ 5 experimental recipes
>
> On Tue, 2013-07-16 at 17:28 +0300, Cristian Iorga wrote:
>> Observe my investigation below in order to decide if RREPLACES is needed.
>> Conclusion: BlueZ 5.x will be eventually an upgrade path for an 
>> already installed embedded device. As such, RREPLACES is needed for a system-wide upgrade.
>
> It wasn't very obvious to me that these results make a compelling case for bluez4 needing to RREPLACE bluez5.  Indeed, this section:
>
> root at qemux86:~# opkg install bluez5
> Multiple replacers for bluez5, using first one (bluez4).
> Package bluez4 is already installed on root.
> root at qemux86:~# opkg list-installed | grep bluez
> bluez4 - 4.101-r6.0
> libasound-module-bluez - 4.101-r6.0
>
> ... seems to illustrate (modulo the usual amount of opkg craziness) why having it be so is not a very good thing.
>
> p.
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>



More information about the Openembedded-core mailing list