Re: [OE-core] [PATCH 3/7] sstatesig/find_siginfo: unify a disjointed API

2024-01-05 Thread Richard Purdie
On Fri, 2024-01-05 at 12:42 +0100, Alexander Kanavin wrote: > On Fri, 5 Jan 2024 at 12:22, Richard Purdie > wrote: > > > 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

Re: [OE-core] [PATCH 3/7] sstatesig/find_siginfo: unify a disjointed API

2024-01-05 Thread Alexander Kanavin
On Fri, 5 Jan 2024 at 12:22, Richard Purdie wrote: > 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 :/. There's the option of adding another function (fi

Re: [OE-core] [PATCH 3/7] sstatesig/find_siginfo: unify a disjointed API

2024-01-05 Thread Richard Purdie
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 A

[OE-core] [PATCH 3/7] sstatesig/find_siginfo: unify a disjointed API

2023-12-18 Thread Alexander Kanavin
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 ti