Re: Eliminating dependency race-conditions

[Esben Haabendal <eha@doredevelopment.dk>]

Phil Blundell <philb@gnu.org> writes:

> On Fri, 2011-03-18 at 06:29 +0100, Esben Haabendal wrote:
>> Yes, I get your point.  You could of-course still specify build
>> dependencies using recipe names/provides, and then just unpack all
>> target packages build by that recipe.
>> 
>> This would give you the major part of the KISS win I see, except for in
>> the dependency handling code of BitBake (and in the learning curve of OE
>> developers).  Keep in mind that by using packages for build-time
>> dependencies, the mechanism is exactly identical for run-time and
>> build-time dependencies.  Exactly the same code in BitBake handles both,
>> and the same mechanism needs to be understood.  This is also part of the
>> KISS win of doing it this way.
>
> Right.  So, it seems to me that the appropriate way to attack the
> problem in OE is to start by doing exactly that: leave the syntax of
> DEPENDS alone for now, treat each entry in DEPENDS as meaning "all
> packages built by the named recipe", and then implement the per-recipe
> sysroot construction that I think we are agreed is highly desirable.

By doing it this way, I don't think we are getting much closer to the
second step (package-based build-time dependencies).  The OE-lite
implementation of per-recipe staging builds on top of package-based
build-time dependencies, so to do it the other way around, would imply
taking the sstate concept and extend it to do per-recipe sysroots.
After that, I believe you have exactly the same amount of development
left to get where OE-lite is in respect to package-based build-time
depencies and per-recipe staging.

As I see it, package-based build-time dependencies practically obsoletes
sstate.  So if we for a moment imagine that we have moved OE to have
sstate based per-recipe staging, we still have the same amount of work
to do in the following areas:

* Modifying BitBake and OE metadata to handle package-based build-time
  dependencies
* Modifying existing recipes to include package-based build-time
  dependency information

You can see the per-recipe staging as a postive side-effect of the
package-based build-time dependency implementation.

So why take the detour instead of just doing it?

> Then, as a later refinement, we could introduce a mechanism for
> specifying dependencies more precisely, at the package level rather than
> the recipe level.  We could do that either by extending the syntax of
> DEPENDS, something like:
>
> DEPENDS = "boost:boost-iostreams"
>
> (to say that you wanted just the boost-iostreams package from the boost
> recipe)

That is IMO just adding more cruft to OE.  Not really what we need.

> or, alternately, by introducing a new variable which would either
> supplement or replace DEPENDS.  Either of those would allow us to
> migrate to fine-grained dependencies without breaking existing recipes.

Sounds better.

Also, just as for run-time dependencies, the build-time package
dependencies is not necesarely the actual package names, but some
provides names, so having a "recipe:package" syntax really does not make
much sense.

>> > (How) do you deal with library package renaming in OE-lite?
>> 
>> What exactly do you mean?  (We are doing several things with library
>> package naming...)
>
> I was thinking of situations like the Debian package autonamer, ie the
> thing that causes glibc-dev to come out named "libc6-dev.ipk" or similar
> depending on the soname of the library that was built.  It seems like
> this would be a bit awkward to deal with if your dependencies were
> specified purely in terms of output packages.

As OE-lite is not OE, we are currently not supporting such type of
package renaming.  Let's leave that to Debian guys to fight with ;-)

But as we build-time dependencies are typically in the form of some
package "provides", it doesn't really matter if the package is renamed.

/Esben