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

Saul Wold sgw at linux.intel.com
Tue Jul 16 14:47:40 UTC 2013


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