[OE-core] sstate hash equivalence breaks rm_work

[Richard Purdie]

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
:/

Cheers,

Richard