On Mon, 2023-12-18 at 09:43 +0100, Alexander Kanavin wrote:
> find_siginfo() returns two different data structures depending
> on whether its third argument (list of hashes to find) is empty or
> not:
> - a dict of timestamps keyed by path
> - a dict of paths keyed by hash
> 
> This is not a good API design; it's much better to return
> a dict of dicts that include both timestamp and path, keyed by
> hash. Then the API consumer can decide how they want to use these
> fields, particularly for additional diagnostics or informational
> output.
> 
> I also took the opportunity to add a binary field that
> tells if the match came from sstate or local stamps dir, which
> will help prioritize local stamps when looking up most
> recent task signatures.
> 
> Signed-off-by: Alexander Kanavin <[email protected]>
> ---
>  meta/lib/oe/buildhistory_analysis.py        |  2 +-
>  meta/lib/oe/sstatesig.py                    | 31 +++++++++------------
>  meta/lib/oeqa/selftest/cases/sstatetests.py | 10 +++----
>  3 files changed, 19 insertions(+), 24 deletions(-)

I can see why you've done this. I had thought this might have been a
compatibility issue but it wasn't, it was just bad design from the
start (and I wasn't responsible for it for a change!).

It gives me a real headache for merging though since it requires OE-
Core and bitbake to change in lockstep.

There is a risk people might just update bitbake but not OE-Core and
also vice versa, they update OE-Core but not bitbake. This can happen
for all kinds of reasons, e.g. mixing a newer bitbake with an older
release.

The latter is easy to address with a bitbake version check bit the
former is not really possible to detect with our current code as
bitbake can't know OE-Core doesn't support what it needs.

With other changes in the pipeline like inherit_defer and the fact
there is a bug related to this on a stable branch, it makes it all the
more likely people will try and mix/match different versions.

I've a few ideas on how we might be able to detect potential problems,
I'll continue to try and work something out but I want to make it clear
there are some things it is hard to change :/.

Cheers,

Richard






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#193351): 
https://lists.openembedded.org/g/openembedded-core/message/193351
Mute This Topic: https://lists.openembedded.org/mt/103239349/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to