Re: Eliminating dependency race-conditions (was Re: [PATCH] net-snmp: disable libnl use)

[Phil Blundell <philb@gnu.org>]

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.

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)

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.

> > (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.

p.