From: Koen Kooi <k.kooi@student.utwente.nl>
To: Using the OpenEmbedded metadata to build Distributions
<openembedded-devel@openembedded.org>
Subject: Re: Cleaning up SDK/Toolchain
Date: Wed, 24 Oct 2007 22:34:05 +0200 [thread overview]
Message-ID: <471FAC3D.7030301@student.utwente.nl> (raw)
In-Reply-To: <1193077473.6088.68.camel@localhost.localdomain>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Richard Purdie schreef:
> On Mon, 2007-10-22 at 17:34 +0200, Koen Kooi wrote:
>> Richard Purdie schreef:
>>> * Each machine could have its own staging area. To do that you'd have to
>>> make the populate staging stamp machine specific. That is possible
>>> although bitbake might require some tweaks and it would have
>>> implications for rm_work.
>> In essence it would make multimachine unimachine :(
>
> Not necessarily. Only the populate_staging task would be machine
> specific, not the all the tasks.
>
> With the staging changes I'm thinking of, do_populate_staging basically
> becomes a file copy. For the numbers of files we're talking about, it
> should be fast. rm_work would still work as long as it preserved the
> image directory under work...
So:
* rm_work deletes ${S} when used
* do_clean deletes ${WORKDIR} when used and kills stamps
* do_stage() copies files from ${WORKDIR}/image/ to staging/machine-tuple/
did I understand that correctly?
regards,
Koen
>
>>> * We implement packaged staging and only stage the dependencies needed
>>> for each package.
>> That would be a better approach. Graeme, do you still want to have a
>> shot at implementing a unionfs based approach?
>
> Hmm. Does that need root privs?
>
> Richard
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFHH6w9MkyGM64RGpERAsPdAKCYsjAOTF+R5zmCnEjr7cqsodJiWQCfWhG7
ZUKW4Ca9hANBG+LC5j/ejJE=
=edFM
-----END PGP SIGNATURE-----
prev parent reply other threads:[~2007-10-24 20:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-17 13:25 Cleaning up SDK/Toolchain Michael 'Mickey' Lauer
2007-10-18 9:39 ` Koen Kooi
2007-10-18 11:59 ` Richard Purdie
2007-10-18 13:44 ` Koen Kooi
2007-10-18 17:30 ` Koen Kooi
2007-10-22 11:39 ` Koen Kooi
2007-10-22 14:36 ` Richard Purdie
2007-10-22 15:34 ` Koen Kooi
2007-10-22 16:43 ` Graeme Gregory
2007-10-22 18:24 ` Richard Purdie
2007-10-22 20:46 ` Leon Woestenberg
2007-10-22 21:02 ` Graeme Gregory
2007-10-23 2:33 ` mwester
2007-10-24 20:34 ` Koen Kooi [this message]
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=471FAC3D.7030301@student.utwente.nl \
--to=k.kooi@student.utwente.nl \
--cc=openembedded-devel@lists.openembedded.org \
--cc=openembedded-devel@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 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.