[OE-core] [PATCHv2 1/2] postinst-intercept: New recipe to include postinstall intercepts in nativesdk

[Otavio Salvador]

On Thu, Jan 23, 2014 at 6:39 AM, David Nyström
<david.c.nystrom at gmail.com> wrote:
> 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 at 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 at 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 at enea.com>
>>>>
>>>>
>>>>
>>>> Much better. Thanks.
>>>>
>>>> Reviewed-by: Otavio Salvador <otavio at 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.

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.

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.

-- 
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