[oe] [PATCH] packagekit: Updated to 0.8.13

[Felipe Tonello]

Hi Koen,

On Thu, Nov 28, 2013 at 3:03 AM, Koen Kooi <koen at dominion.thruhere.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Paul Eggleton schreef op 28-11-13 11:58:
>> On Thursday 28 November 2013 11:49:18 Koen Kooi wrote:
>>> Paul Eggleton schreef op 28-11-13 11:32:
>>>> Hi Koen / Felipe,
>>>>
>>>> On Thursday 28 November 2013 10:22:31 Koen Kooi wrote:
>>>>> Felipe F. Tonello schreef op 28-11-13 01:56:
>>>>>> From: "Felipe F. Tonello" <eu at felipetonello.com> This recipe
>>>>>> supports the backend for packagekit dynamically based on the
>>>>>> IMAGE_PKGTYPE.
>>>>>
>>>>> NAK! IMAGE_FEATURES should *never* change non-image recipe params.
>>>>> This breaks using feeds horribly.
>>>>
>>>> IMAGE_PKGTYPE is influenced by PACKAGE_CLASSES; so this is not about
>>>> IMAGE_FEATURES, and correct me if I'm wrong but maintaining package
>>>> feeds
>>>>
>>>> would generally preclude switching to an alternative package
>>>> manager,
>>>>
>>>> right?
>>>
>>> No, it's perfectly possible to build both opkg and rpm, which is what
>>> I'm currently doing. When doing that the DISTRO.conf does need to make
>>> a decision on what to support for things like packagekit.
>>>
>>>> Some options:
>>>>
>>>> 1) Apply the patch as-is. Changing the order/value of
>>>> PACKAGE_CLASSES will mean this and anything that depends upon it will
>>>> rebuild.
>>>>
>>>> 2) Install the appropriate backend via some code in the image
>>>> recipe. Obviously this means you have to do this for every image
>>>> recipe though.
>>>>
>>>> 3) Use non-dynamic PACKAGECONFIG. Of course this means you'll have
>>>> to remember to change this manually if you change PACKAGE_CLASSES or
>>>> it'll just be broken at runtime.
>>>>
>>>> Honestly, option 1 sounds like the best course to me here. This is
>>>> rather a special case compared to other recipes.
>>>
>>> 1) will let you end up with packagekit_1.0.ipk that only supports RPM
>>
>> Correct, it would. I agree that's not ideal. Neither is having it broken
>> by default for some people though (unless you just set all backends to on
>> by default, that is.)
>>
>>> 2) Is what we would really want, but I don't think packagekit supports
>>> that :(
>>
>> This patch looks like it is splitting out the backends into separate
>> packages...
>
> If that's the case, 2) is the route to go.
>

It does split into packages. I splited it up in packages just so if
the user wants to have different backend options, it can.

The problem with this aproach, is that you will add the apt and opkg
dependency to the build even if the user doesn't care about it. I
don't like this option to be honest.

Felipe