On Wed, Feb 09, 2022 at 01:40:22PM +0000, Richard Purdie wrote: > On Wed, 2022-02-09 at 13:27 +0000, [email protected] 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161563): https://lists.openembedded.org/g/openembedded-core/message/161563 Mute This Topic: https://lists.openembedded.org/mt/89018266/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
