[poky] RFC/RFT Checksums as part of stamp files

[Tian, Kevin]

>From: Richard Purdie
>Sent: Friday, January 07, 2011 6:56 AM
>
>We've been working on checksums and sstate for a while, one of the
>pieces we've not put in place so far is using the checksums in the stamp
>files.
>
>What this would mean in English is the end of PR bumps since when you
>change the recipe, the checksums of the appropriate tasks change and
>everything automatically rebuilds that changed.
>
>It also means if you change something in the core packaging, everything
>should repackage and so on.
>
>The final key to enabling this is this commit:
>
>http://git.pokylinux.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/bitbake-wip&id=b82259
>b901cae11b0e5715a92a580c9432af52cc
>
>This hasn't been merged to master yet but we should discuss when this
>change could/should be merged and under what criteria.
>
>I've only just started testing full builds with the change myself so
>keep that in mind. I'd appreciate testing but the change is still very
>new and likely has bugs to iron out.

I can help test it out too.

>
>I'm also aware that this idea isn't going to be universally liked,
>particularly I can guess that Koen is going to have concerns about this
>and Angstrom since the lack of PR bumps means package feeds could start
>to suffer.

worthy of a config option? We may need see from real use whether this will
trigger many unnecessary rebuilds and how much impact to people's daily
work. Basically the incremental builds will be much more heavier than before,
though this in concept is more correct...

>
>My proposal for dealing with this will be to start having the packaging
>backend take ownership of PE and PR fields. These should be auto
>incremented when the build changes. That in itself is easy enough if you
>have one build area, the tricky bit is where you have multiple build
>sources feeding into a common packages repo like Angstrom.
>
>For this we're going to need some kind of network service that takes a
>version and provides the PE/PR values back, incrementing them each time
>it sees a new version/checksum.
>
>This would solve one of Koen's major complaints about PR bumps in
>general once and for all but there is some effort needed to implement
>something that could provide this service.
>
>Also, on the plus side, we could also now make image generation a
>"stamp" task with a stamp that will only change when the image inputs
>change. That would change a users expectations in some regard so again
>needs discussion.
>


Thanks
Kevin