[yocto] [PATCH V4 03/10] utils.py: remove obsolete dependencies

Paul Eggleton paul.eggleton at linux.intel.com
Thu Jun 22 04:54:22 PDT 2017

On Thursday, 22 June 2017 12:47:31 PM CEST Robert Yang wrote:
> On 06/21/2017 05:06 PM, Paul Eggleton wrote:
> > So I do see the need to clear out old dependency values when your list of
> > dependencies is coming entirely from LAYERDEPENDS, however if you have only
> > manually added dependencies and LAYERDEPENDS is not complete (as is often the
> > case in the OE layer index), will this automatically remove those? If so I
> The dependencies will be removed if it is not in conf/layer.conf.
> > think we're going to have to come up with some mechanism to avoid that.
> > Probably the easiest one would be to avoid touching the dependencies unless
> > LAYERDEPENDS actually changes. Of course if that means we're going to store
> > the previous LAYERDEPENDS value somewhere to compare to, we'd need to avoid it
> > triggering initially when none of those values are set.
> Why not fix conf/layer.conf rather than fix it from database ? If
> conf/layer.conf is wrong, we would meet problems elsewhere. 

Up until now it hasn't caused any issues other than not getting an error
up front from bitbake when a dependencies are missing, so it can easily go
unnoticed (particularly when users follow manual instructions or use existing
configurations rather than an automated tool that pays attention to

> The database
> should obey local.conf when mismatches, otherwise, this would confuse
> users a lot when they want to update LAYERDEPENDS.

As I indicated, I agree that if LAYERDEPENDS gets updated then the
dependencies in the database should get updated. My concern is updating
them if LAYERDEPENDS has not changed and it simply happens to have
a difference to what is in the database (most importantly if it has less
dependencies specified).

> I'm glad to fix oe-classic's LAYERDEPENDS issues if they are wrong.

Well, it's not so much OE-Classic as every single layer in the index,
maintained by a number of different maintainers. I agree in the long term we
do want people to fix their dependencies. The trouble is we don't
even know the size of the problem at the moment, and if it's widespread
then we'll end up dropping dependencies potentially leading to errors during

How about this - could we start with a setting in the configuration that
specifies that dependencies should be updated automatically, and if not
set just gives a warning if the dependencies are not the same? We can
then decide how to handle it when we see the warnings we're getting in
the OE index.



Paul Eggleton
Intel Open Source Technology Centre

More information about the yocto mailing list