[OE-core] PRSERVER is killing settop boxes

[Richard Purdie]

On Sat, 2014-07-19 at 14:10 +0200, Mike Looijmans wrote:
> For a hobby project (openpli.org) there are about a million boxes 
> running software built with OE.
> 
> I recently upgraded its core to the current master. What now happens is 
> that if a package like gcc has been changed, it will not only rebuild 
> everything, but it will also give all packages a new PR number. When a 
> box in the field now runs "opkg upgrade", it will get 286 "new" packages 
> and will try to squeeze them into its flash filesystem (even though only 
> about 5 of these packages actually have different content). This is 
> likely to kill the box, as the packages installed later on will take up 
> more room in the flash system than when they were initially installed 
> from scratch, and many models are using over 90% of the NAND flash space 
> available already.
> 
> Before the PRSERVER was made mandatory, we never had this problem.
> 
> Is there a way we can get the old behaviour of having to explicitly set 
> the PR of each package?
> Or at least, distinguish between "the package itself was modified" and 
> "some library it depended upon was altered and we built a new one just 
> to make sure, but it'll likely work just fine with the previously built 
> one, so don't update the PR of the dependent packages".

The key question is how do you tell that?

Its always been assumed that we should be able to add some kind of
binary diff tooling onto the end result and then only upgrade the
package, if it really did change (for whatever value of 'change' you
configure).

The issue is that as yet, nobody has actually written that tool. The old
PR bump approach wasn't much better since the right ones never seemed to
get bumped, I was forever getting complaints that the wrong things
changed and I can guarantee you'd have more than 5 new packages even on
the old system.

So the best way forward is some kind of binary history/comparison
tooling interfacing to the PR server but who is going to write that and
when, I don't know. Do I regret moving away from the manual PR bump
model? No, not really, it was a mess.

To be honest, I get depressed when I read things like this. There are
key pieces of functionality we're missing and we simply do not have the
developer manpower to be able to go and fix them all. I want to help but
I'm drowning just trying to keep the day to day project and patches
flowing and generally I never hear about the successes, just when
people's builds break (which is always *my* fault and must be fixed
*now*).

I'd love to see more organisations donating some man power to address
issues like this. People see the project basically keeping moving and
therefore decide to put manpower on things closer to home though. I wish
I knew how to try and improve things, I don't even get the time to step
back and think about that these days though :(.

Cheers,

Richard