[Openembedded-architecture] Making PRSERV more useful binary feeds
Richard Purdie
richard.purdie at linuxfoundation.org
Mon Apr 11 16:07:24 UTC 2016
On Mon, 2016-04-11 at 17:29 +0200, Koen Kooi wrote:
> I think that PRSERV should return max(PR_arch1, PR_arch2, PR_arch3,
> .. PR_archN) instead of PR_archX. My main usecase is having
> consistency between the different architectures in my feeds. With the
> above I can safely say “r0.48 and newer has fixes for $CVE”, which I
> currently cannot do.
The way the code works is it gets a hash which represents the current
build, it compares this to the last known value for the current arch
and then if it matches returns the old value, if it doesn't, it
increases and returns a new value whilst writing a new entry to the DB.
If you try and make these match between arches, the code can tell if
the hash changes, but it can't tell whether it should increase to the
greatest existing value, or that greatest value+1 since it doesn't know
whether two hashes are "equivalanet" or not.
Put another way, if you do this, I think things will get out of sync
and you'll get spiralling PR values rather than the consistent ones you
want.
I'm not sure how to get you what you want offhand :/.
> Also: why is ‘bitbake-prserv-tool-export foo.conf’ taking more time
> than parsing all the metadata from scratch? It should be a simple
> sqlite read and reformat, no?
Good question. Its probably something nobody's looked at from an
optimisation perspective. There are very few people ever look at the
codebase from a performance perspective :(
Cheers,
Richard
More information about the Openembedded-architecture
mailing list