[oe] Revisiting bitbake stamp handling

[Richard Purdie]

On Wed, 2007-09-19 at 05:29 +0200, Koen Kooi wrote:
> > Say you're using rm_work and want to rebuild strace for the image. You
> > run "bitbake strace -c compile -f". A subsequent "bitbake someimage"
> > will not cause strace to install/package/stage or get included in the
> > image. Broken and one of the things you wanted to fix!
> 
> Actually, that would work, since -c compile -f would update the do_compile stamp, so its
> mtime is newer than the do_rootfs.

do_rootfs is stampless. 

> > Say you want to trigger a reinstall of all packages like the recent
> > pkgmaps change. How do you do it? In the case without rm_work you could
> > touch all a dependent task like compile to trigger the install (ugly),
> > or remove *every* install task stamp and *every* stamp which depends on
> > install (near impossible). With rm_work, you're screwed basically.
> 
> Which highlights exactly why the current situation is broken. In this case the user has to
> discover he needs to run install again (which a lot of them don't, looking at IRC and the
> ml), so what's stopping us from adding an do_installall task that does exactly that? Or
> even requiring a rebuild, since it needs the user to find out *and* the user to take action.

I don't see how a communication issue is related to the need to add a
do_installall task?

Cheers,

Richard