On Fri, Jan 24, 2014 at 6:51 AM, David Nyström <[email protected]> wrote: > 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.
In April master is going to be 1.6, thus a stable. > 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 ? The point here is implementation wise. >> 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. Well, until complete we cannot known what will be the size of it. I will let others comment and give their view of it. I'd prefer it to be in a layer for now. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
