Re: sstate hash equivalence breaks rm_work

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 3175 bytes --]

On Mon, Mar 04, 2019 at 04:21:48PM +0000, Richard Purdie wrote:
> On Mon, 2019-03-04 at 11:14 -0500, Tom Rini wrote:
> > On Mon, Mar 04, 2019 at 04:06:47PM +0000, Richard Purdie wrote:
> > > You mean like the BB_MIN_VERSION variable:
> > > 
> > > http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/sanity.conf#n6
> > > 
> > > ?
> > > 
> > > :)
> > > 
> > > The changes were intended to be backwards compatible hence it
> > > wasn't
> > > bumped. Clearly something isn't playing as intended...
> > 
> > Yes, that.  I think we haven't fully used that well historically
> > since I can only ever recall *kaboom* when using too old of a bitbake
> > rather than a nice sane error message.  Looking at
> > https://wiki.yoctoproject.org/wiki/Releases and then some quick git
> > history, we also must have had that mechanism available when I last
> > ran into something like that even for the fairly ancient jumping
> > around I've had to do a time or three.
> 
> That variable has been around for a long time. It does get incremented
> when we do nasty things which we know break things. If something sneaks
> in, its more problematic. We do try and avoid API breakage.
> 
> > In fact, can we make BB_MIN_VERSION match the table found there?  It
> > doesn't look like we have resources / time to test things on both
> > current and min versions, so we should I think have the min match
> > what we say should be used.
> 
> The problem is more "test what?" on the min version. In this case its
> rm_work which triggers it, the bugs tend to be unusual corner cases
> which our test matrix, vast as it is might not catch. Case in hand, we
> don't test rm_work on the autobuilder.
> 
> I'm torn on forcing people to update, I've had a lot of complaints
> about being being forced when they didn't need to in the past. Its also
> true that we're not as backwards compatible as we could be, i.e. using
> a modern bitbake on old metadata isn't always guaranteed either due to
> the same kinds of problems :(.
> 
> By this line of argument, we'd bump the minor bitbake version for every
> bug fix and force people to it, just to "protect" them from themselves
> :/

So, what's worse, people hit a bug that's fixed in a newer version, or
when people upgrade one set of branches they have to update another
repository too?

Honestly, I could see the "but why do I have to update bitbake too?"
complaint being more reasonable back in the early days after we moved to
proper layers.  Now that it's not just oe-core/poky but also
meta-openembedded and meta-$BSP and maybe 2-5 other layers you also need
to bump from branch to branch, adding bitbake to that mix seems a lot
less of a big deal.

I thought about this and re-drafted something a few times now.  I think
perhaps a happy compromise would be to move the BB_MIN_VERSION check
from a hard-failure to the same level of warning we do on
SANITY_TESTED_DISTROS, and make it track the suggested version for a
release.  This will both help to catch bugs that have been fixed already
but still let people that know what they want (or don't want) to do, do
it.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]