Re: [PATCH] sstate.bbclass: preserve time when unstaging files

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

On Mon, 2012-10-29 at 18:59 +0100, Enrico Scholz wrote:
> Richard Purdie <richard.purdie@linuxfoundation.org> writes:
> 
> >> > where the option was added deliberately to deal with time mismatch
> >> > between autobuilders which was causing real world bugs.
> >> 
> >> But the real bug is the time mismatch in the autobuilders, isn't it?
> >> And this can/should be solved by synchronizing time by ntp on them
> >> instead of applying dirty hacks like resetting file dates.
> >
> > I have asked that ntp be installed/fixed on the autobuilders to sort the
> > problem out but it seems that even with ntp running, mismatches can
> > happen (e.g. misconfigured timezones).
> 
> Really? The only timezone related problems might arise when a package
> makes 'touch -d <date>' during build.  But I can not remember that I
> have ever seen such a package and this problem should be easy to
> localize.
> 
> Else, timezone configuration is completely uninteresting for comparing
> timestamps or for setting time from ntp.
>
> > Worse, when this does happen the failures are extremely unpredictable
> > and hard to debug. It causes things to repeatedly recompile for example,
> > even during do_install.
> 
> How comes do_install() into the game?  'populate-lic' are the only
> sstate files created before do_install() and I can not imagine how they
> affect the other build phases; do_compile() results are not sstated
> (and with the 'tar -m' thing, timestamps get havoc completely causing
> unpredictable rebuilds).
> 
> When do_install() is executed, all the following sstate files
> (populate_sysroot, package) are invalidated and must be recreated.  So
> your problem with do_install() sounds more like an incomplete/racy
> cleanup of old files.

Set the date stamp of some headers in the target sysroot of some key
system components (say glib) to a date about a day in the future, then
clean and rebuild some software that uses glib.

You will find that every time the recipe runs make, *everything* will
recompile. This will happen during do_install as well as do_compile and
if you recipe calls make for any other reason, it will recompile again.

Normally the builds actually tolerate this quite well, until you get
something like qt4 where the do_install environment isn't setup to
support compiling and then things explode in interesting ways.

Cheers,

Richard