[oe] [beagleboard] Re: Beagle actions for Rev C validation software image

[Jason Kridner]

On Tue, Jan 27, 2009 at 3:55 PM, Koen Kooi <koen at beagleboard.org> wrote:
>
> Op 27 jan 2009, om 22:54 heeft Jason Kridner het volgende geschreven:
>
>>
>> On Tue, Jan 27, 2009 at 3:48 PM, Koen Kooi <k.kooi at student.utwente.nl>
>> wrote:
>>>
>>> On 27-01-09 22:02, Denys Dmytriyenko wrote:
>>>>
>>>> On Tue, Jan 27, 2009 at 12:19:36PM -0600, Jason Kridner wrote:
>>>>>
>>>>> Adding oe-dev mailing list...
>>>>>
>>>>> On Tue, Jan 27, 2009 at 12:10 PM, Dmytriyenko, Denys<denys at ti.com>
>>>>> wrote:
>>>>>>>>
>>>>>>>> It's a bit sad that we're going to miss out on NEON and vo_omapfb by
>>>>>>>> going armv5te :(
>>>>>>>
>>>>>>> Koen,
>>>>>>> I am rebuilding 'mplayer' now with 'MACHINE=beagleboard bitbake
>>>>>>> mplayer',
>>>>>>> so that concern should go away.  It shouldn't matter much about this
>>>>>>> mplayer, since it should only be used to test the hardware.
>>>>>>> Can you consider inclusion of:
>>>>>>> mplayer and FFmpeg dependency changes:
>>>>>>>
>>>>>>>
>>>>>>> http://www.beagleboard.org/gitweb/?p=arago-oe.git;a=commitdiff_plain;h=0b53219005c8daa95bcff40742d7c807bda17eca
>>>>>>
>>>>>> Hmm, I like these curl-inspired *_FEATURES handlers. The only problem
>>>>>> with
>>>>>> those is they won't trigger automatic rebuild when the featureset in
>>>>>> the
>>>>>> variable changes - don't forget to run bitbake -c rebuild manually...
>>>>>
>>>>> Can I get a few comments on [1]?  I found there is also a dependency
>>>>> in libtheora on x11 that doesn't seem necessary.  I find this very
>>>>> useful to avoid making a new recipe.  Anyone have ideas to address
>>>>> Denys' concern about needing to issue 'bitbake -c rebuild'?
>>>>>
>>>>> [1]
>>>>>
>>>>> http://www.beagleboard.org/gitweb/?p=arago-oe.git;a=commitdiff_plain;h=0b53219005c8daa95bcff40742d7c807bda17eca
>>>>
>>>> For some reason Koen's reply never made it to the oe-dev list... Sorry
>>>> for
>>>> copying it here to continue the discussion.
>>>>
>>>> Koen said:
>>>>>
>>>>> I'm against adding such 'USE flags' to OE, they basically make QA
>>>>> impossible.
>>>>> If people want a different mplayer, they are free to make an
>>>>> 'mplayer-nox' or
>>>>> 'mplayer-nosdl' recipe to fill their needs.
>>>>
>>>> But on the other hand it would make overlays, such as Arago, as well as
>>>> OE
>>>> itself, much cleaner and reduce the recipe creep.
>>>>
>>>> As of the rebuild issue when featureset in the variable changes, I was
>>>> thinking about storing a hash of variable's value, in addition to the
>>>> standard version and revision numbers, should trigger an automatic
>>>> rebuild.
>>>> Similar to bumping up a PR, but without modifying the recipe. Any
>>>> thoughts?
>>>
>>> I'm concerned with mplayer_1.0_armv7a.ipk not being the same as
>>> mplayer_1.0_armv7a.ipk, which is what USE flags do.
>>
>> Is it possible in OE to generate an ipk file name that gives some
>> indication of the USE flags?  Perhaps the right way to do this is with
>> a common .inc file to avoid maintenance issues.
>
> If it magically mangles package names, what's so different from creating
> multiple recipes?

I think the differences are the names being sensible (based on having
multiple recipes and using a .inc file to avoid maintenance issues)
vs. maintaining fewer recipes.  The USE flags also give greater
flexibility at the distribution level, but I've only seen a limited
number of cases for which this is currently required.  As long as the
recipes give ?= assignments, "personal" distributions could still be
generated at the local.conf level.  The idea to add a hash to trigger
an automatic rebuild if relevant USE flags change still seems quite
useful (and even putting the USE flags into the control file).