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

[David Nyström]

On 2014-01-23 11:56, Otavio Salvador wrote:
> 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.

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.