All of lore.kernel.org
 help / color / mirror / Atom feed
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: Wed, 22 Jan 2014 19:02:52 +0100	[thread overview]
Message-ID: <52E007CC.5070405@gmail.com> (raw)
In-Reply-To: <CAP9ODKr4WxcPVkxGMR+ZZ98b6mLbmUyr9Qs=BWe-S5HVJSn=hg@mail.gmail.com>

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.

Br,
David



  reply	other threads:[~2014-01-22 18:02 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 [this message]
2014-01-22 18:11     ` Otavio Salvador
2014-01-22 18:26       ` David Nyström
2014-01-23  8:39       ` David Nyström
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=52E007CC.5070405@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.