[oe] checksums situation

[Richard Purdie]

On Wed, 2009-02-25 at 18:04 -0500, Denys Dmytriyenko wrote:
> I'm not in the position to explain how Bitbake works to the Bitbake's core 
> developer and maintainer. :) So, below is just my understanding of how it 
> works.
> 
> So, for overlays it currently works the same way for checksums.ini as it does 
> for conf/class files - it uses only one instance of a file with the same name, 
> depending on the priority either from overlay or from upstream org.oe.dev. In 
> other words - if my overlay has a higher priority, it would use my 
> checksums.ini INSTEAD of the upstream one in org.oe.dev. Same with conf/class 
> files - if I have a copy of base.bbclass in my overlay, it REPLACES the one 
> from upstream org.oe.dev...

There are two different mechanisms that bitbake uses to find files. One
is the conf/class mechanism using BBPATH, the other is the BBFILES
mechanism and collections (overlays).

For BBFILES, we have some globs which expand into a list of files.
Depending on some pattern matching, they get given different priorities
so files from a given collection can "win" compared to those from
another. This is what you describe above and as you rightly point out it
wouldn't work for checksums.ini files.

When we need a conf file, say "bitbake.conf" we search through BBPATH,
appending "conf/" to each entry and seeing if it exists. The first match
found wins. Class files work similarly.

For checksum.ini I'm proposing we'd go through BBPATH and append all the
checksum.ini files found together to form one large complete version.
People's overlay/collections can then supplement the checksum data
easily. There certainly isn't a technical reason I can see why this
wouldn't work.

Cheers,

Richard