On 2014-01-23 11:56, Otavio Salvador wrote:
On Thu, Jan 23, 2014 at 6:39 AM, David Nyström
<[email protected]> wrote:
On ons 22 jan 2014 19:11:21, Otavio Salvador wrote:
On Wed, Jan 22, 2014 at 4:02 PM, David Nyström
<[email protected]> wrote:
On ons 22 jan 2014 16:47:06, Otavio Salvador wrote:
On Wed, Jan 22, 2014 at 1:08 PM, David Nyström
<[email protected]> 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 <[email protected]>
Much better. Thanks.
Reviewed-by: Otavio Salvador <[email protected]>
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.
I agree with the principle but I think we can accomplish the same with
a layer, if properly announced and put in layer index.
The reason I dislike this WIP to be in OE-Core is that implementation
starts to be considered stable and people and projects starts to
depends on it so changing it radically is hard as we need to carry
backward compatibility.
We need to carry backward compatibility ?.
In a stable branch I would agree to this, but not in master.
When the sstate was introduced and developed, you mean it never broke
the ABI from then till now ?
Buildhistory DB ABI, license report formats, build output directory
renaming, naming conventions never broke the ABI ?
Can you give any other examples of where new functionality additions
were rejected due to the non-stable clause ?
Don't take me wrong, I do think this is important and I do think this
ought to be in OE-Core but I am unsure about it being mature enough
for it.
This will be a quite minimal layer containing these 2 patches, and one
more upcoming nativesdk-nss patch.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
