From: "David Nyström" <david.c.nystrom@gmail.com>
To: Otavio Salvador <otavio@ossystems.com.br>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCHv2 1/2] postinst-intercept: New recipe to include postinstall intercepts in nativesdk
Date: Thu, 23 Jan 2014 09:39:21 +0100 [thread overview]
Message-ID: <52E0D539.9090402@gmail.com> (raw)
In-Reply-To: <CAP9ODKpAQDTg-UV-vR4419Q+6zvt=xNL=Wo5dH+feQi4wsWiGQ@mail.gmail.com>
On ons 22 jan 2014 19:11:21, Otavio Salvador wrote:
> On Wed, Jan 22, 2014 at 4:02 PM, David Nyström
> <david.c.nystrom@gmail.com> wrote:
>> On ons 22 jan 2014 16:47:06, Otavio Salvador wrote:
>>>
>>> On Wed, Jan 22, 2014 at 1:08 PM, David Nyström
>>> <david.c.nystrom@gmail.com> wrote:
>>>>
>>>> Adding ability to use postinstalls intercepts in the nativesdk env, and
>>>> making sure the correlate between repo + SDK.
>>>>
>>>> This to enable rootfs generation from a package repository using only a
>>>> package repository and the toolchain tarball.
>>>>
>>>> See https://github.com/nysan/rootfs-sandbox for examples.
>>>>
>>>> Signed-off-by: David Nyström <david.nystrom@enea.com>
>>>
>>>
>>> Much better. Thanks.
>>>
>>> Reviewed-by: Otavio Salvador <otavio@ossystems.com.br>
>>>
>>> Regarding the rootfs-sandbox, how are you intending to proper
>>> integrate it with the toolchain?
>>>
>>
>> Search the oe-core list for the previous discussions with Tom Zanussi.
>> I believe the long term goals is to redo rootfs_*.bbclass in python, and let
>> both bitbake and MIC(WIC) use
>> the same code for image creation.(SDK env + bitbake env.)
>>
>> I'm fine with continued dev/inclusion of rootfs-sandbox, but I think that
>> might not be acceptable as a long term solution since
>> it may be maintenance heavy, since it uses alot of oe-core internal env.
>> vars.
>>
>> Possible routes are:
>> 1. Use common code for rootfs assembly. (WIC)
>> 2. Cleanup env. var. usage in postinstall hooks, and be aggressive in
>> denying new additions. (Continue dev. on rootfs-sandbox)
>>
>> Off-topic:
>> With above patches, I'm down to 1 postinstall failures for
>> packagegroup-core-lsb:
>> 1. missing shlibsign, (nss), cant get the damn thing to compile for
>> nativesdk yet.
>>
>> There are 2 other failures as well, but they fail when bitbake:ing as well.
>> Only works well with ipk sofar.
>
> So I think we ought to work on this in a layer and put things in
> OE-Core when it is ready.
>
> What do you think?
>
Sorry, read your mail again, I think I misunderstood.
For rootfs-sandbox I agree, this is WIP.
I suspect that others already have these features, and regardless of
WIC or rootfs-sandbox or other.
they will need the same functionality exposed in the SDK.
We are working on the same thing here, and as such, I think the small
pieces needed to do this should be centralized in oe-core so
we can cooperate around them, and define interfaces between the SDK and
bitbake env in an open environment.
Br,
David
next prev parent reply other threads:[~2014-01-23 8:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-22 15:08 [PATCHv2 1/2] postinst-intercept: New recipe to include postinstall intercepts in nativesdk David Nyström
2014-01-22 15:08 ` [PATCHv2 2/2] nativesdk-packagegroup-sdk-host: Adding nativesdk-postinst-intercept to SDK David Nyström
2014-01-22 15:47 ` [PATCHv2 1/2] postinst-intercept: New recipe to include postinstall intercepts in nativesdk Otavio Salvador
2014-01-22 18:02 ` David Nyström
2014-01-22 18:11 ` Otavio Salvador
2014-01-22 18:26 ` David Nyström
2014-01-23 8:39 ` David Nyström [this message]
2014-01-23 10:56 ` Otavio Salvador
2014-01-24 8:51 ` David Nyström
2014-01-24 11:15 ` Otavio Salvador
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=52E0D539.9090402@gmail.com \
--to=david.c.nystrom@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=otavio@ossystems.com.br \
/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.