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

[Otavio Salvador]

On Fri, Jan 24, 2014 at 6:51 AM, David Nyström
<david.c.nystrom at gmail.com> wrote:
> 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.

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