How to move a recipe to another directory without invalidating its sstate-cache?

I renamed "recipes-some/foo/bar.bb" to "recipes-some/buzz/bar.bb"

Rebuilding bar and its dependencies will take about 16 hours. So I don't want
to trigger a rebuild.

running "bitbake -S printdiff bar" only reveils this:

Quoted 7 lines · Mike Looijmans

I renamed "recipes-some/foo/bar.bb" to "recipes-some/buzz/bar.bb"

Rebuilding bar and its dependencies will take about 16 hours. So I don't want
to trigger a rebuild.

running "bitbake -S printdiff bar" only reveils this:

I'm not sure I trust the output of -S printdiff, there are some cases it doesn't seem to "guess" right. I wish I or someone one could fix but but we can do its work manually. Can you try something like:

set TMPDIR = "x"
bitbake -S bar
rename the recipe
set TMPDIR = "y"
bitbake -S bar

then

"ls tmp-x/stamps/xxxx/bar"
"ls tmp-y/stamps/xxxx/bar"

and see which tasks change signature. Then run:

"bitbake-diffsigs <sig A> <sig B>"

and see if that makes more sense?

Quoted 13 lines · Richard Purdie

Quoted 7 lines · Mike Looijmans

I renamed "recipes-some/foo/bar.bb" to "recipes-some/buzz/bar.bb"

Rebuilding bar and its dependencies will take about 16 hours. So I don't want
to trigger a rebuild.

running "bitbake -S printdiff bar" only reveils this:

I'm not sure I trust the output of -S printdiff, there are some cases it doesn't seem to "guess" right. I wish I or someone one could fix but but we can do its work manually. Can you try something like:

Quoted 5 lines

set TMPDIR = "x"
bitbake -S bar
rename the recipe
set TMPDIR = "y"
bitbake -S bar

Found out I need an extra "none" in here:
bitbake -S none bar

Quoted 10 lines

then

"ls tmp-x/stamps/xxxx/bar"
"ls tmp-y/stamps/xxxx/bar"

and see which tasks change signature. Then run:

"bitbake-diffsigs <sig A> <sig B>"

Quoted 1 line

and see if that makes more sense?

That gave the same output. Everything after "runtaskdeps" is bogus because its value changes from [blahblah, foobar] into [buzbar, blahblah] and now diffsig seems to attempt to match the "blahblah" signatures against those of "buzbar".

Which sort of hints that if my new name starts with an "f" the reordering won't happen, so I'm gonna try renaming to "fbuz" now,,,

Quoted 17 lines · Richard Purdie

Quoted 9 lines · Mike Looijmans

I renamed "recipes-some/foo/bar.bb" to "recipes
-some/buzz/bar.bb"

Rebuilding bar and its dependencies will take about 16 hours. So I
don't want
to trigger a rebuild.

running "bitbake -S printdiff bar" only reveils this:

I'm not sure I trust the output of -S printdiff, there are some cases
it doesn't seem to "guess" right. I wish I or someone one could fix but
but we can do its work manually. Can you try something like:

Quoted 5 lines

set TMPDIR = "x"
bitbake -S bar
rename the recipe
set TMPDIR = "y"
bitbake -S bar

Found out I need an extra "none" in here:
bitbake -S none bar

Quoted 10 lines

then

"ls tmp-x/stamps/xxxx/bar"
"ls tmp-y/stamps/xxxx/bar"

and see which tasks change signature. Then run:

"bitbake-diffsigs <sig A> <sig B>"

and see if that makes more sense?

That gave the same output. Everything after "runtaskdeps" is bogus because its
value changes from [blahblah, foobar] into [buzbar, blahblah] and now diffsig
seems to attempt to match the "blahblah" signatures against those of "buzbar".

Which sort of hints that if my new name starts with an "f" the reordering
won't happen, so I'm gonna try renaming to "fbuz" now,,,

Quoted 18 lines · Mike Looijmans

Quoted 17 lines · Richard Purdie

Quoted 9 lines · Mike Looijmans

I renamed "recipes-some/foo/bar.bb" to "recipes
-some/buzz/bar.bb"

Rebuilding bar and its dependencies will take about 16 hours. So I
don't want
to trigger a rebuild.

running "bitbake -S printdiff bar" only reveils this:

I'm not sure I trust the output of -S printdiff, there are some cases
it doesn't seem to "guess" right. I wish I or someone one could fix but
but we can do its work manually. Can you try something like:

Quoted 8 lines

Quoted 5 lines

set TMPDIR = "x"
bitbake -S bar
rename the recipe
set TMPDIR = "y"
bitbake -S bar

Found out I need an extra "none" in here:
bitbake -S none bar

Sorry, yes.

Quoted 18 lines

Quoted 10 lines

then

"ls tmp-x/stamps/xxxx/bar"
"ls tmp-y/stamps/xxxx/bar"

and see which tasks change signature. Then run:

"bitbake-diffsigs <sig A> <sig B>"

and see if that makes more sense?

That gave the same output. Everything after "runtaskdeps" is bogus because its
value changes from [blahblah, foobar] into [buzbar, blahblah] and now diffsig
seems to attempt to match the "blahblah" signatures against those of "buzbar".

Quoted 3 lines

Which sort of hints that if my new name starts with an "f" the reordering
won't happen, so I'm gonna try renaming to "fbuz" now,,,

I still suspect this might be the way the tool displays the data rather than the real problem as there is some fuzziness in the data that code has to work with. Bitbake just knows there are dependencies on hashes X, Y, Z and it has to try and guess how to match them up. The paths are included to help reduce fuzz but are only used by the analysis code, not the checksum creation.

Did the hashes themselves change or just the paths? I'm wondering if the order that bitbake adds the checksums to the main checksum may have some bearing on this...

Being able to see some real data would also help. Does this reproduce with a public recipe I can see the real data for?

Quoted 52 lines · Richard Purdie

Quoted 18 lines · Mike Looijmans

Quoted 17 lines · Richard Purdie

Quoted 9 lines · Mike Looijmans

I renamed "recipes-some/foo/bar.bb" to "recipes
-some/buzz/bar.bb"

Rebuilding bar and its dependencies will take about 16 hours. So I
don't want
to trigger a rebuild.

running "bitbake -S printdiff bar" only reveils this:

I'm not sure I trust the output of -S printdiff, there are some cases
it doesn't seem to "guess" right. I wish I or someone one could fix but
but we can do its work manually. Can you try something like:

Quoted 8 lines

Quoted 5 lines

set TMPDIR = "x"
bitbake -S bar
rename the recipe
set TMPDIR = "y"
bitbake -S bar

Found out I need an extra "none" in here:
bitbake -S none bar

Sorry, yes.

Quoted 18 lines

Quoted 10 lines

then

"ls tmp-x/stamps/xxxx/bar"
"ls tmp-y/stamps/xxxx/bar"

and see which tasks change signature. Then run:

"bitbake-diffsigs <sig A> <sig B>"

and see if that makes more sense?

That gave the same output. Everything after "runtaskdeps" is bogus because its
value changes from [blahblah, foobar] into [buzbar, blahblah] and now diffsig
seems to attempt to match the "blahblah" signatures against those of "buzbar".

Quoted 3 lines

Which sort of hints that if my new name starts with an "f" the reordering
won't happen, so I'm gonna try renaming to "fbuz" now,,,

Quoted 6 lines

I still suspect this might be the way the tool displays the data rather than the real problem as there is some fuzziness in the data that code has to work with. Bitbake just knows there are dependencies on hashes X, Y, Z and it has to try and guess how to match them up. The paths are included to help reduce fuzz but are only used by the analysis code, not the checksum creation.

No, if the sort order doesn't change, the checksum remains the same as well.

So if i rename "foo" to "far" it will not rebuild the package (using plain bitbake without -S switches), but if I rename "foo" to "buz" it will rebuild because there's a dependent package that sorts before "far" but after "buz".

Quoted 6 lines

Did the hashes themselves change or just the paths? I'm wondering if the order that bitbake adds the checksums to the main checksum may have some bearing on this...

Being able to see some real data would also help. Does this reproduce with a public recipe I can see the real data for?

There should be quite a few recipes in OE-core that might match this pattern:

Recipe X must depend on recipe Y. The directory of Y sorts before that of X. Renaming the directory of X to something that sorts before that of Y should trigger the problem.

I'll see if I can locate an existing one.