From: Esben Haabendal <eha@dev.doredevelopment.dk>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: yocto <yocto@yoctoproject.org>, poky <poky@yoctoproject.org>
Subject: Re: Shared State - What does it mean and why should I care?
Date: Mon, 25 Apr 2011 09:48:13 +0200 [thread overview]
Message-ID: <1303717693.964.10.camel@eha> (raw)
In-Reply-To: <1300408987.30423.2172.camel@rex>
On Fri, 2011-03-18 at 00:43 +0000, Richard Purdie wrote:
> As a real world example, the aim is when building an ipk based image,
> only the do_package_write_ipk tasks would have their sstate packages
> fetched and extracted. Since the sysroot isn't used, it would never get
> extracted. This is another reason to prefer the task based approach
> sstate takes over any recipe based approach which would have to install
> the output from every task.
In case anyone cares, the "per-recipe based staging" used in OE-lite,
and proposed as a future design concept for OE-core (although clearly
not going to be used in OE-core anytime soon) is also task based in the
above context, and has the same advantage as described for sstate above.
I just wanted to make the point as the "any recipe based approach" could
easily give casual readers the assumption that this was a weak point in
my proposal.
/Esben
WARNING: multiple messages have this Message-ID (diff)
From: Esben Haabendal <eha@dev.doredevelopment.dk>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: yocto <yocto@yoctoproject.org>, poky <poky@yoctoproject.org>
Subject: Re: [poky] Shared State - What does it mean and why should I care?
Date: Mon, 25 Apr 2011 09:48:13 +0200 [thread overview]
Message-ID: <1303717693.964.10.camel@eha> (raw)
In-Reply-To: <1300408987.30423.2172.camel@rex>
On Fri, 2011-03-18 at 00:43 +0000, Richard Purdie wrote:
> As a real world example, the aim is when building an ipk based image,
> only the do_package_write_ipk tasks would have their sstate packages
> fetched and extracted. Since the sysroot isn't used, it would never get
> extracted. This is another reason to prefer the task based approach
> sstate takes over any recipe based approach which would have to install
> the output from every task.
In case anyone cares, the "per-recipe based staging" used in OE-lite,
and proposed as a future design concept for OE-core (although clearly
not going to be used in OE-core anytime soon) is also task based in the
above context, and has the same advantage as described for sstate above.
I just wanted to make the point as the "any recipe based approach" could
easily give casual readers the assumption that this was a weak point in
my proposal.
/Esben
next prev parent reply other threads:[~2011-04-25 7:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-18 0:43 Shared State - What does it mean and why should I care? Richard Purdie
2011-04-20 16:45 ` Darren Hart
2011-04-20 16:45 ` [poky] " Darren Hart
2011-04-20 16:58 ` Rifenbark, Scott M
2011-04-20 16:58 ` [poky] " Rifenbark, Scott M
2011-04-20 17:20 ` Adrian Alonso
2011-04-20 17:20 ` [poky] " Adrian Alonso
2011-04-20 22:14 ` Richard Purdie
2011-04-20 22:14 ` [poky] " Richard Purdie
2011-04-25 7:48 ` Esben Haabendal [this message]
2011-04-25 7:48 ` Esben Haabendal
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=1303717693.964.10.camel@eha \
--to=eha@dev.doredevelopment.dk \
--cc=poky@yoctoproject.org \
--cc=richard.purdie@linuxfoundation.org \
--cc=yocto@yoctoproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.