From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] image.bbclass: Don't mark do_rootfs and do_build as nostamp
Date: Mon, 29 Apr 2013 15:45:01 +0100 [thread overview]
Message-ID: <2359996.YCG7Bud1Ca@helios> (raw)
In-Reply-To: <1367053734.29677.91.camel@ted>
On Saturday 27 April 2013 10:08:54 Richard Purdie wrote:
> On Sat, 2013-04-27 at 09:34 +0100, Paul Eggleton wrote:
> > On Friday 26 April 2013 12:30:38 Phil Blundell wrote:
> > > There doesn't appear to be any compelling reason for these tasks to be
> > > nostamp and having them re-run on every build can be irritating (for
> > > example, when the image is an initramfs which your kernel image depends
> > > on).
> > >
> > > Signed-off-by: Phil Blundell <philb@gnu.org>
> > > ---
> > >
> > > meta/classes/image.bbclass | 2 --
> > > 1 file changed, 2 deletions(-)
> > >
> > > diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> > > index ffb372a..667d03d 100644
> > > --- a/meta/classes/image.bbclass
> > > +++ b/meta/classes/image.bbclass
> > > @@ -168,11 +168,9 @@ LINGUAS_INSTALL ?= "${@" ".join(map(lambda s:
> > > "locale-base-%s" % s, d.getVar('IM
> > >
> > > PSEUDO_PASSWD = "${IMAGE_ROOTFS}"
> > >
> > > -do_rootfs[nostamp] = "1"
> > >
> > > do_rootfs[dirs] = "${TOPDIR} ${WORKDIR}/intercept_scripts"
> > > do_rootfs[lockfiles] += "${IMAGE_ROOTFS}.lock"
> > > do_rootfs[cleandirs] += "${S} ${WORKDIR}/intercept_scripts"
> > >
> > > -do_build[nostamp] = "1"
> > >
> > > # Must call real_do_rootfs() from inside here, rather than as a
> > > separate
> > > # task, so that we have a single fakeroot context for the whole
> > > process.
> >
> > I have to say I'm not in favour of this. AFAIK these tasks have always
> > been
> > nostamp, and I'm not sure making do_build is going to help for the case
> > you
> > cite because the dependency on INITRD_IMAGE is on do_rootfs.
> >
> > If you're concerned about your initramfs image rebuilding when building
> > the
> > main image, what happens if you specify do_rootfs[nostamp] = "0" ?
>
> I think this deserves some further thought. It is a pretty major change
> however it is something I've wondered about for a while independently of
> Phil, I've just never proposed a patch.
>
> It might help to think about this in an alternative way. Before we has
> the sstate checksums, it was near impossible to know when the inputs to
> an image had changed and when they had not. Now with the sstate
> checksums, we can know when any given input has changed and if it has
> changed, the sstate checksum changes and the task re-runs.
>
> You can therefore make the case that these "nostamp" tasks are a legacy
> of the former world and that now, there is no compelling reason to have
> them as nostamp. If you particularly want to force them to run, we do
> have the -f option and its tainting works here just as well as it does
> anywhere else.
>
> If the rootfs nostamp is removed, there is no reason to have build as a
> nostamp either, they were there as a pair.
So upon further reflection, I'm guessing my objections were only really about
changing the status quo, as well as a lot of my own testing involving re-
running the image creation step without really changing anything other than
the code that contributes to do_rootfs; it could be argued that my use case
would be equally served by me setting nostamp locally or using -f, and
everyone else having the benefit of not rebuilding the image when not needed.
Given that this is a departure from previously established behaviour, I do
think we need to give a more of an explanation in the commit message than the
proposed patch however; something that summarises Richard's explanation above
would be informative.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
next prev parent reply other threads:[~2013-04-29 15:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-26 11:30 [PATCH] image.bbclass: Don't mark do_rootfs and do_build as nostamp Phil Blundell
2013-04-27 8:34 ` Paul Eggleton
2013-04-27 9:08 ` Richard Purdie
2013-04-27 9:20 ` Koen Kooi
2013-04-29 14:45 ` Paul Eggleton [this message]
2013-04-29 14:54 ` Richard Purdie
2013-04-29 18:33 ` Phil Blundell
2013-05-02 18:05 ` Saul Wold
2013-04-27 9:24 ` Phil Blundell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2359996.YCG7Bud1Ca@helios \
--to=paul.eggleton@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox