[bitbake-devel] [PATCH 1/1] die if a .bbappend file matches no existing .bb recipe

[Richard Purdie]

On Mon, 2011-06-27 at 07:05 -0700, Chris Larson wrote:
> On Mon, Jun 27, 2011 at 6:49 AM, Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
> > On Fri, 2011-06-24 at 14:38 -0400, Denys Dmytriyenko wrote:
> >> On Fri, Jun 24, 2011 at 11:16:53AM -0700, Chris Larson wrote:
> >> > On Mon, Jun 20, 2011 at 12:29 AM, Cui, Dexuan <dexuan.cui at intel.com> wrote:
> >> > > Martin Jansa wrote:
> >> > >> On Mon, Jun 20, 2011 at 6:34 AM, Dexuan Cui <dexuan.cui at intel.com>
> >> > >> wrote:
> >> > >>> This patch moves the logic of show_appends_with_no_recipes from
> >> > >>> bitbake-layers into bitbake, and makes the script die with a fatal
> >> > >>> error message printed.
> >> > >>
> >> > >> I agree that this is problem, but I'm not sure if it should be fatal.
> >> > >>
> >> > >> Imagine the case when you enable some layer managed by someone else
> >> > >> (lets call it LS) and you're using different oe-core revision, maybe
> >> > >> current HEAD and that LS wasn't updated for that or vice versa you're
> >> > >> using some oe-core release version and you want to reuse some recipes
> >> > >> from LS in current version.
> >> > >>
> >> > >> I think that big fat warning that some .bbappends does not match
> >> > >> should be enough to decide if it's fatal for me (and I'll kill that
> >> > >> build) or that's fine (when I'm not interested in those .bbappends
> >> > >> from LS and I'm using only some other .bb files from LS).
> >> > >>
> >> > >> If we make it fatal then I would be forced to remove unmatched
> >> > >> .bbappends from LS before build which can be difficult to share
> >> > >> (unless I create own LS branch and use it in my distro).
> >> > > Thanks a lot for the explanation!
> >> > > So looks we may as well change the "bb.fatal" to "bb.error"(that is not
> >> > > fatal and wouldn't be ignored by bitbake-layers).
> >> > > This is the new patch (on a new branch dcui/bb-v2):
> >> > > http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a
> >> >
> >> > Are you sure this shouldn't be a warning? Remember that any error
> >> > displayed results in a non-zero exit code from bitbake.
> >>
> >> So, speaking of which - what is the practical use for bb.error? It gives an
> >> error message, but doesn't stop the build. Although it returns a non-zero exit
> >> code, which for most autobuilders indicate a failed build anyway... What's the
> >> point?
> >
> > It denotes something which the user really needs to know about and fix.
> > The sanity tests are good example and I'd really like to see sanity
> > issues becoming bb.errors in most cases.
> >
> > You can also think about it as being a point on the error severity
> > scale:
> >
> > Note: Information only
> > Warning: Something happened which the user likely needs to fix
> > Error: Something happened the user is strongly recommended to fix - set
> >       exit code accordingly.
> > Fatal: Something bad happened and there is no hope so stop.
> >
> > I think in the scheme of different error priorities and actions, it
> > makes sense...
> 
> I really don't think they're very useful right now. If our UIs
> actually captured the errors and summarized them at the end of the
> build, as well as had them in a global log, then I could see them
> being of use, but having an error message that might have scrolled
> past an hour ago result in a non-zero exit code is far from ideal. As
> a user, I have no idea why it seems to have failed.

Well, patches to improve the UIs in the regard are welcome. At least at
this point we can do this kind of thing at the UI level which is way
better than the situation used to be.

I'd also argue its better to have any indication there was a problem
than none at all...

Cheers,

Richard