[Angstrom-devel] bitbake angstrom-console-image failing onprocps

[Michael Krelin]

> Hello Michael,
> 
>       You don't cc: list, right?

It was a mistake on my part, I just hit "reply". I think I won't 
rebounce my message to the list, since you have preserved my comments.

>>>   Depends. Such attitude makes builds less deterministic - different
>>> parties may have differently built packages which however has the same
>>> revision. It also may mean that context-dependent bugs may go
>>> unnoticed to bite later - for example, it builds for some people,
>>> doesn't build for you, you apply patch, which makes it build for you,
>>> and regresses for the others, yet this go unnoticed for them until
>>> they bother to rebuild from scratch. Btw, recently we discussed an
>>> issue which was kinda close to this description, right?
> 
>> Right (although, while we're at it, it seems to have been preferred 
>> versions issue, as my build of 1.2.3 went fine). And, basically, I'm not
>> going to argue. Your point is quite valid. Neither it invalidates mine,
>> which is: we should not ease development at the expense of end user 
>> (that is - binaries user).
> 
>   Maybe, when we have something "stable". But for now, OE.dev is
> developer's galore.

But if we don't establish some sane practices it will always be.

>> Moreover, the mere *possibility* of not 
>> bumping PR is a reason for doing automated builds from scratch once in a
>> while itself.
> 
>   Your welcome to join in with the stuff, especially taking into
> account, there's not dedicated, public, visible CI system for OE at
> all ;-).

Thanks for the invitation ;-)

>>>   So, it's of course a compromise of pragmatism and formality, but
>>> having other ratio might be helpful. For example, for gcc or glibc, it
>>> would be desirable to avoid semi-spurious bumps, yet for other stuff
>>> which are many it's easier to bump and forget (but let people remind
>>> you soon if something's wrong).
> 
>> I think theoretically it's possible to satisfy both of us without 
>> compromising much. How about having a bitbake mode that figures which 
>> packages to rebuild based on involved files *timestamps*? This mode 
>> would be suitable for automated build and update paranoids. Or, some 
>> kind of "build-PR"?
> 
>   Dunno. I got used to bitbake's rebuild dependency tracking as it is,
> and it works for me *and* for users who want deterministic system -
> changes is package building result in package revision bumping, which
> is exactly how it should be.

It's your "should", which I do not completely agree with. I just 
suggested the way it "should" be in my opinion. This way we pay users 
without robbing developers and vice versa.

Love,
H