[oe] Eliminating dependency race-conditions (was Re: [PATCH] net-snmp: disable libnl use)
Phil Blundell
philb at gnu.org
Fri Mar 18 10:26:27 UTC 2011
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.
More information about the Openembedded-devel
mailing list