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

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

[David Nyström]

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@enea.com>
---
 .../postinst-intercept/postinst-intercept_1.0.bb      | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 meta/recipes-devtools/postinst-intercept/postinst-intercept_1.0.bb

diff --git a/meta/recipes-devtools/postinst-intercept/postinst-intercept_1.0.bb b/meta/recipes-devtools/postinst-intercept/postinst-intercept_1.0.bb
new file mode 100644
index 0000000..41b9a6e
--- /dev/null
+++ b/meta/recipes-devtools/postinst-intercept/postinst-intercept_1.0.bb
@@ -0,0 +1,19 @@
+SUMMARY = "Postinstall scriptlets"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+
+FILES_${PN}_append_class-nativesdk = " ${datadir}/postinst-intercepts/*"
+
+do_configure[noexec] = "1"
+do_compile[noexec] = "1"
+
+do_install_append_class-nativesdk() {
+	install -d ${D}${datadir}/postinst-intercepts
+	install -m 755 ${COREBASE}/scripts/postinst-intercepts/postinst_intercept ${D}${datadir}/postinst-intercepts/
+	install -m 755 ${COREBASE}/scripts/postinst-intercepts/update_font_cache ${D}${datadir}/postinst-intercepts/
+	install -m 755 ${COREBASE}/scripts/postinst-intercepts/update_icon_cache ${D}${datadir}/postinst-intercepts/
+	install -m 755 ${COREBASE}/scripts/postinst-intercepts/update_pixbuf_cache ${D}${datadir}/postinst-intercepts/
+}
+
+BBCLASSEXTEND = "nativesdk"
+INHIBIT_DEFAULT_DEPS = "1"
-- 
1.8.3.2

[PATCHv2 2/2] nativesdk-packagegroup-sdk-host: Adding nativesdk-postinst-intercept to SDK

[David Nyström]

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@enea.com>
---
 meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
index 1065f30..f1bc1ea 100644
--- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
+++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
@@ -23,6 +23,7 @@ RDEPENDS_${PN} = "\
     nativesdk-shadow \
     nativesdk-makedevs \
     nativesdk-smartpm \
+    nativesdk-postinst-intercept \
     "
 
 RDEPENDS_${PN}_darwin = "\
-- 
1.8.3.2

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

[Otavio Salvador]

On Wed, Jan 22, 2014 at 1:08 PM, David Nyström
<david.c.nystrom@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@enea.com>

Much better. Thanks.

Reviewed-by: Otavio Salvador <otavio@ossystems.com.br>

Regarding the rootfs-sandbox, how are you intending to proper
integrate it with the toolchain?

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

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

[David Nyström]

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@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@enea.com>
>
> Much better. Thanks.
>
> Reviewed-by: Otavio Salvador <otavio@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.

Br,
David

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

[Otavio Salvador]

On Wed, Jan 22, 2014 at 4:02 PM, David Nyström
<david.c.nystrom@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@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@enea.com>
>>
>>
>> Much better. Thanks.
>>
>> Reviewed-by: Otavio Salvador <otavio@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?

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

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

[David Nyström]

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@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@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@enea.com>
>>>
>>>
>>> Much better. Thanks.
>>>
>>> Reviewed-by: Otavio Salvador <otavio@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?
>

Well, the WIC is a slightly different approach.
I obviously prefer this method, since you can work against and expand 
the target rootfs, the nativesdk and target sysroots via the repo,
and do it iteratively.
But there is also parts missing in this approach that would need to be 
replicated.
SD-card creation, partitioning, FS conversion et.c.

However, I have no problems with including it others +1:s this.

Br,
David

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

[David Nyström]

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@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@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@enea.com>
>>>
>>>
>>> Much better. Thanks.
>>>
>>> Reviewed-by: Otavio Salvador <otavio@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.

Br,
David

Re: [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@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@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@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@enea.com>
>>>>
>>>>
>>>>
>>>> Much better. Thanks.
>>>>
>>>> Reviewed-by: Otavio Salvador <otavio@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

Re: [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@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@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@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@enea.com>
>>>>>
>>>>>
>>>>>
>>>>> Much better. Thanks.
>>>>>
>>>>> Reviewed-by: Otavio Salvador <otavio@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.

Re: [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@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@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@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@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@enea.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Much better. Thanks.
>>>>>>
>>>>>> Reviewed-by: Otavio Salvador <otavio@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