Re: [OE-core] [poky][master][PATCHv2] buildhistory.bbclass: Enable exporting more recipe and package data

[<Mikko.Rapeli@bmw.de>]

On Wed, Feb 09, 2022 at 01:40:22PM +0000, Richard Purdie wrote:
> On Wed, 2022-02-09 at 13:27 +0000, Mikko.Rapeli@bmw.de wrote:
> > Hi,
> > 
> > On Wed, Feb 09, 2022 at 12:23:39PM +0000, Richard Purdie wrote:
> > > People have requested changes like this before and I rejected it as I'm worried
> > > that allowing people to customise this code will just fork the project into many
> > > different directions. 
> > 
> > It's the other way round. There are a lot of needs to extract metadata from
> > build system into something where reports can be generated.
> 
> I don't doubt that however buildhistory was written for a specific purpose and
> if we start adding the ability to customise it heavily we lose the ability for
> comparisions to be made, or sstate reuse and so on.
> 
> I'm partly channelling the original author's views on this since they had some
> very specific thoughts on this change. I do sometimes wonder if I should
> continue doing that though :/.

Then how should yocto users export CVE_NAME, LICENSE, PN, PV, SRC_URI etc from
the build system to generate SW bill of materials (BOM) for their product
and track progress?

Yes, SPDX can be the other answer but I don't find that human readable or working
out of the box atm.

> >  I'd prefer this to be buildhistory as it also tracks progress across releases and 
> > versions and custom builds if the setup has been done correctly. If this change isn't 
> > going to be accepted, projects need to continue with their custom patches on top of 
> > current buildhistory bbclass in poky.
> > 
> > > The elif block above illustrates part of my concern since it still isn't scaling
> > > well and just potentially makes every buildhistory output difference (even with
> > > different ordering). There are reasons the data is taken from pkginfo rather
> > > than getVar too and I think this could introduce subtle bugs in the future.
> > 
> > The elif block is just for backwards compatibility. Changing the order of fields would
> > be annoying in buildhistory. The new ones will be in alphabetical order so I don't
> > think this is so bad. It is possibly to completely rewrite and simplify buildhistory
> > but this would be annoying for users who actually track the changes.
> >
> > > Which variables are you actually interested in when changing this?
> > 
> > LICENSE, CVE_PRODUCT, SRC_URI, MAINTAINER and some project specific variables too.
> > It is very useful to have these tracked in buildhistory git repo where differences
> > between releases can easily be seen.
> 
> The trouble is this turns it into a "metadata difference" tool rather than a
> build output difference tool which is different to the design. It also makes it
> much harder to write the buildhistory analysis tool since all of a sudden we're
> dealing with any variable rather than package specific ones and we can no longer
> assume any particular output would be present (and it is no longer just based
> upon packagedata).

What tool or feature from yocto should we use then?

> I guess we can see what others think, but I am concerned about letting people
> remove existing output from it too.

Well buildhistory can have defaults. It can be extended. I don't see your reasons
for limiting the output to a few variables which you care about.

I frequently debug issues by looking at buildhistory data about images, binary
packages and recipes. It is a very useful tool.

-Mikko