Re: [PATCH 0/2] Allow oe-pkgdata-util package-info to display more info

[Peter Kjellerstedt <peter.kjellerstedt@axis.com>]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Peter Kjellerstedt
> Sent: den 16 maj 2017 18:30
> To: Richard Purdie <richard.purdie@linuxfoundation.org>
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 0/2] Allow oe-pkgdata-util package-info
> to display more info
> 
> > -----Original Message-----
> > From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
> > Sent: den 16 maj 2017 15:15
> > To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; openembedded-
> > core@lists.openembedded.org
> > Subject: Re: [OE-core] [PATCH 0/2] Allow oe-pkgdata-util package-info
> > to display more info
> >
> > On Tue, 2017-05-16 at 12:56 +0200, Peter Kjellerstedt wrote:
> > > After a build in our autobuilder, we use `oe-pkgdata-util package-
> > > info -f package.manifest` to store a file with information about 
> > > each installed package. This is typically used to compare builds 
> > > later on. Since not every difference to a package is explained by 
> > > its version, we have found it beneficial to also include the 
> > > SRC_URI in the generated file.
> > >
> > > This patch set adds SRC_URI to the pkgdata that is stored for each
> > > package, and adds a new option to oe-pkgdata-util package-info,
> > > -e <var>, that can be used to display extra variables from the
> > > pkgdata.
> >
> > I'm going to say no to this.
> >
> > The reason is that pkgdata is not really about collecting up all
> > build information. If you want to know how two different builds 
> > differ, you'd use the sigdata files. If I take this patch, more 
> > will follow where you find some new difference you want to track 
> > and there are other mechanisms I'd suggest (buildhistory and 
> > siginfo for starters). I don't want to turn the pkgdata files 
> > into something they're not.
> >
> > Cheers,
> >
> > Richard
> 
> As you may have expected, that was not the response I had hoped for.
> However, I will see if we can come to a working solution that you can
> accept.
> 
> Since I hope that the change to oe-pkgdata-util is acceptable to you,
> I will focus on the change in package.bbclass.
> 
> Regarding siginfo: I assume it has the information in there somewhere.
> However, I have been working with OE for five years now, and it is
> still basically a black hole to me. I have no idea how to do anything 
> useful with it.
> 
> Regarding buildhistory: AFAICT there is nothing in there about neither
> recipe names nor SRC_URI. I guess that can be added, though, if really
> needed.
> 
> On the other hand, we have a tool, oe-pkgdata-util, that provides a
> simple interface to access the package information, and can produce a
> simple information file (oe-pkgdata-util package-info) with one line
> per package. This file is simple enough that I can give it to our
> maintenance team and they can look at it to see if there are any
> differences they need to know about. An additional benefit here is that
> we can run oe-pkgdata-util from within a bitbake task to generate the
> file together with the other artefacts we produce for a release.
> 
> That said, I can understand that you do not want to add information to
> the pkgdata that is not really needed to build. However, would you
> accept a way to add to this data, e.g., by specifying a BitBake variable 
> such as EXTRA_PKGDATA_VARS with the names of the extra variables that 
> should be stored in pkgdata? That way it would not affect anyone unless 
> they actually need this extra data, and I would not have the burden of
> carrying a backported version of package.bbclass forever in our layers 
> with all the extra maintenance that incurs.
> 
> //Peter

It has been a week now. Any response would be appreciated.

//Peter