[oe] Eliminating dependency race-conditions

[Frans Meulenbroeks]

2011/3/16 Esben Haabendal <eha at doredevelopment.dk>:
> On Tue, 2011-03-15 at 18:03 -0400, Denys Dmytriyenko wrote:
>> On Tue, Mar 15, 2011 at 10:08:37AM +0100, Esben Haabendal wrote:
>> > On Fri, 2011-03-11 at 12:04 +0100, Steffen Sledz wrote:
>> > > which occurred sometimes depending on build order (not in clean
>> > > package only builds).
>> >
>> > I would like to raise awareness of the underlying problem here.
>> >
>> > The current dependency/staging model of OE basically has this feature
>> > that a build can be influenced not only by it's own dependencies, but
>> > also what has been build before it (or not).
>> >
>> > I strongly believe that this has to be fixed on the architectural level,
>> > and not just on a case-by-case level as is currently needed.
>> >
>> > I haven't received much feedback on the preivous posting about the
>> > per-recipe staging principle implemented in OE-lite, but I decided to
>> > take this opportunity to re-iterate the fact that the OE-lite
>> > implementation of staging and build dependencies eliminates this
>> > problem.
>> >
>> > I am still very much interested in discussing how to move this
>> > technology from OE-lite to OE, but as it impacts all recipe metadata
>> > (build dependencies has to be redefined), OE community at a large really
>> > needs to value the benefits of solving this problem.
>>
>> Esben,
>>
>> Thanks for raising this issue and making people aware of it!
>>
>> This has previously been discussed several times, including last time during
>> the Yocto Summit in December, where I brought up the question of per-package
>> staging/dependency to Richard's attention, when he introduced the new Shared
>> State (sstate). While per-package dependency wasn't considered a critical
>> must-have feature right away, it was acknowledged as something worthwhile
>> looking at and, according to Richard, should be easy to accomplish with the
>> new sstate functionality...
>
> There is two different objectives in this.
>
> Per-recipe staging and per-package build-time dependencies.  While I
> assume per-recipe staging will be doable to build on top of sstate,
> per-package build-time dependencies is not really related to sstate, but
> is mostly a meta-data issue (man-hours wise), while also requiring
> changes to tbe BitBake cooker.
>
> The final thing that I have found while solving the above issues, is how
> simple (KISS!) all this can be addressed when going from per-recipe
> build-time dependencies to per-package.  And I really think that we need
> more KISS in OE ;-)
>
> /Esben

>From a consistency point of view per package build-time dependencies
are highly desirable to get a consistent and reproducible system as
you are always getting the same output irrespective of build order.
Currently this is not the case because configure might pick up
whatever package is build first.
So for (deeply) embedded product development this is a very desirable
feature, QA wise, if not a must have.

Frans