Re: PRServer's problem

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2016-05-19 at 10:47 +0200, Martin Jansa wrote:
> As the commit says, small change in package.bbclass also causes all
> packages to be recreated with PR bump even when the content is most
> likely the same.
> 
> Fixing bug in gcc may at least provide different binaries so it might
> be useful to upgrade them on target (or at least distinguish if they
> were already rebuilt with fixed gcc-cross or not).
>
> Reverting the commit doesn't fix the issue that sstate handler cannot
> compare if the change in signature produced "significantly different"
> binaries. If it's reverted in oe-core I'll just revert the revert in
> our builds, because we care about reproducible builds and we already
> gave up on working upgrade paths, which are broken too often anyway.
> 
> Reflash of "system" partitions and storing user data/configuration
> somewhere else is faster and safer since the sstate was invented
> (since we stopped using OE classic). You can find some rant e-mails
> from me about this e.g.
> http://lists.openembedded.org/pipermail/openembedded-core/2011-Novemb
> er/051354.html
> and the Yocto bug I gave you.

FWIW I've not given up on upgrade paths and I do try and ensure basic
things do get spotted and addressed during review.

IMO, the only way we'll improve the upgrade situation is if someone
writes some automated tests for it, such that when we test changes, we
test the upgrade paths work. We have a ton of test automation now so we
have the basic framework to build something like this on top of. I do
appreciate there are some challenges since it does mean maintaining a
baseline state which the upgrade is tested from (previous state and
previous release being the two obvious ones).

Cheers,

Richard