[PATCH 0/4] fix install package "postinst-intercept pointercal-xinput oprofileui avahi" to image failed

[PATCH 0/4] fix install package "postinst-intercept pointercal-xinput oprofileui avahi" to image failed

[Hongxu Jia]

vim local.conf
...
IMAGE_INSTALL_append = " pointercal-xinput oprofileui avahi"
...

bitbake core-image-minimal

//Hongxu

The following changes since commit 9bfd0dee4f585825f27d314c4fd7cd26cf93da79:

  poky-tiny.conf: remove inherit of blacklist (2014-11-04 15:14:23 +0000)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib hongxu/fix-nonexist-pkg
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/fix-nonexist-pkg

Hongxu Jia (4):
  avahi.inc: use avahi-daemon as avahi's provider
  oprofileui: use oprofileui-viewer as oprofileui's provider
  pointercal-xinput: add the missing ALLOW_EMPTY
  postinst-intercept: rename recipe for nativesdk only

 meta/recipes-connectivity/avahi/avahi.inc                          | 2 ++
 ...stinst-intercept_1.0.bb => nativesdk-postinst-intercept_1.0.bb} | 6 +++---
 meta/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bb   | 1 +
 meta/recipes-kernel/oprofile/oprofileui_git.bb                     | 7 ++++---
 4 files changed, 10 insertions(+), 6 deletions(-)
 rename meta/recipes-devtools/postinst-intercept/{postinst-intercept_1.0.bb => nativesdk-postinst-intercept_1.0.bb} (83%)

-- 
1.9.1

[PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

[Hongxu Jia]

The package avahi does not exist, so we use avahi-daemon as the provider.
It avoids the do_rootfs failure while IMAGE_INSTALL += "avahi"

[YOCTO #6937]

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
 meta/recipes-connectivity/avahi/avahi.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-connectivity/avahi/avahi.inc b/meta/recipes-connectivity/avahi/avahi.inc
index b060437..5573372 100644
--- a/meta/recipes-connectivity/avahi/avahi.inc
+++ b/meta/recipes-connectivity/avahi/avahi.inc
@@ -76,6 +76,8 @@ PACKAGES =+ "avahi-daemon libavahi-common libavahi-core libavahi-client avahi-dn
 # As avahi doesn't put any files into PN, clear the files list to avoid problems
 # if extra libraries appear.
 FILES_avahi = ""
+# Let avahi-daemon to provide avahi
+RPROVIDES_avahi-daemon = "avahi"
 FILES_avahi-autoipd = "${sbindir}/avahi-autoipd \
                        ${sysconfdir}/avahi/avahi-autoipd.action \
                        ${sysconfdir}/dhcp/*/avahi-autoipd \
-- 
1.9.1

Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]

On Fri, Nov 07, 2014 at 03:57:01PM +0800, Hongxu Jia wrote:
> The package avahi does not exist, so we use avahi-daemon as the provider.
> It avoids the do_rootfs failure while IMAGE_INSTALL += "avahi"

Why don't you fix your IMAGE_INSTALL instead?

> 
> [YOCTO #6937]
> 
> Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
> ---
>  meta/recipes-connectivity/avahi/avahi.inc | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/recipes-connectivity/avahi/avahi.inc b/meta/recipes-connectivity/avahi/avahi.inc
> index b060437..5573372 100644
> --- a/meta/recipes-connectivity/avahi/avahi.inc
> +++ b/meta/recipes-connectivity/avahi/avahi.inc
> @@ -76,6 +76,8 @@ PACKAGES =+ "avahi-daemon libavahi-common libavahi-core libavahi-client avahi-dn
>  # As avahi doesn't put any files into PN, clear the files list to avoid problems
>  # if extra libraries appear.
>  FILES_avahi = ""
> +# Let avahi-daemon to provide avahi
> +RPROVIDES_avahi-daemon = "avahi"
>  FILES_avahi-autoipd = "${sbindir}/avahi-autoipd \
>                         ${sysconfdir}/avahi/avahi-autoipd.action \
>                         ${sysconfdir}/dhcp/*/avahi-autoipd \
> -- 
> 1.9.1
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

On 7 November 2014 14:38, Martin Jansa <martin.jansa@gmail.com> wrote:

> On Fri, Nov 07, 2014 at 03:57:01PM +0800, Hongxu Jia wrote:
> > The package avahi does not exist, so we use avahi-daemon as the provider.
> > It avoids the do_rootfs failure while IMAGE_INSTALL += "avahi"
>
> Why don't you fix your IMAGE_INSTALL instead?


Or propose the recipe is changed so that the daemon is in PN (which
rprovides avahi-daemon for compatibility).  Providing PN seems like the
worst solution.

Ross

[-- Attachment #2: Type: text/html, Size: 906 bytes --]

Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

[Hongxu Jia]

[-- Attachment #1: Type: text/plain, Size: 674 bytes --]

On 11/07/2014 10:42 PM, Burton, Ross wrote:
>
> On 7 November 2014 14:38, Martin Jansa <martin.jansa@gmail.com 
> <mailto:martin.jansa@gmail.com>> wrote:
>
>     On Fri, Nov 07, 2014 at 03:57:01PM +0800, Hongxu Jia wrote:
>     > The package avahi does not exist, so we use avahi-daemon as the
>     provider.
>     > It avoids the do_rootfs failure while IMAGE_INSTALL += "avahi"
>
>     Why don't you fix your IMAGE_INSTALL instead?
>
>
> Or propose the recipe is changed so that the daemon is in PN (which 
> rprovides avahi-daemon for compatibility).  Providing PN seems like 
> the worst solution.
>

Good idea, V2 incoming

//Hongxu


> Ross


[-- Attachment #2: Type: text/html, Size: 1989 bytes --]

Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

[Koen Kooi]

> Op 7 nov. 2014, om 15:38 heeft Martin Jansa <martin.jansa@gmail.com> het volgende geschreven:
> 
> On Fri, Nov 07, 2014 at 03:57:01PM +0800, Hongxu Jia wrote:
>> The package avahi does not exist, so we use avahi-daemon as the provider.
>> It avoids the do_rootfs failure while IMAGE_INSTALL += "avahi"
> 
> Why don't you fix your IMAGE_INSTALL instead?

I agree with Martin, this is a non-problem, please fix your IMAGE_INSTALL. 

Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

[Hongxu Jia]

On 11/09/2014 02:53 AM, Koen Kooi wrote:
>> Op 7 nov. 2014, om 15:38 heeft Martin Jansa <martin.jansa@gmail.com> het volgende geschreven:
>>
>> On Fri, Nov 07, 2014 at 03:57:01PM +0800, Hongxu Jia wrote:
>>> The package avahi does not exist, so we use avahi-daemon as the provider.
>>> It avoids the do_rootfs failure while IMAGE_INSTALL += "avahi"
>> Why don't you fix your IMAGE_INSTALL instead?
> I agree with Martin, this is a non-problem, please fix your IMAGE_INSTALL.

I am afraid it is not the issue of IMAGE_INSTALL

As doc said:
http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#var-IMAGE_INSTALL
Variable IMAGE_INSTALL is used to specify the packages to install into 
an image.

While adding some packages to image ,the rpm based do_rootfs
failed with '*** not found in the base feeds'

The failure was caused by two kinds of situations:
1. Package does not exist (such as python3), but provided
    by other package (such as python-core), the rpm based
    do_rootfs could not search its provider. And the deb/
    ipk based do_rootfs worked well, it is a defect, and
    I have fixed it (patch sent to community, YOCTO 6918);

2. Package does not exist, and no other package provides it,
    the package installation will fail in any type do_rootfs. We
    met this issue when we set IMAGE_INSTALL = "recipe_name",
    but we don't have the package with that name.

I think what I do is to fix the situation 2.

Further more, we should add checking at the package generating
time, if the package *with recipe name* was empty and not created,
trigger a warn and according the warn, we could fix the issue recipes.

We already have that checking at the package generating time,
but it a note, not warn. I suggest we should use warn instead.

//Hongxu

Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2690 bytes --]

On Mon, Nov 10, 2014 at 10:02:47AM +0800, Hongxu Jia wrote:
> On 11/09/2014 02:53 AM, Koen Kooi wrote:
> >> Op 7 nov. 2014, om 15:38 heeft Martin Jansa <martin.jansa@gmail.com> het volgende geschreven:
> >>
> >> On Fri, Nov 07, 2014 at 03:57:01PM +0800, Hongxu Jia wrote:
> >>> The package avahi does not exist, so we use avahi-daemon as the provider.
> >>> It avoids the do_rootfs failure while IMAGE_INSTALL += "avahi"
> >> Why don't you fix your IMAGE_INSTALL instead?
> > I agree with Martin, this is a non-problem, please fix your IMAGE_INSTALL.
> 
> I am afraid it is not the issue of IMAGE_INSTALL
> 
> As doc said:
> http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#var-IMAGE_INSTALL
> Variable IMAGE_INSTALL is used to specify the packages to install into 
> an image.
> 
> While adding some packages to image ,the rpm based do_rootfs
> failed with '*** not found in the base feeds'
> 
> The failure was caused by two kinds of situations:
> 1. Package does not exist (such as python3), but provided
>     by other package (such as python-core), the rpm based
>     do_rootfs could not search its provider. And the deb/
>     ipk based do_rootfs worked well, it is a defect, and
>     I have fixed it (patch sent to community, YOCTO 6918);
> 
> 2. Package does not exist, and no other package provides it,
>     the package installation will fail in any type do_rootfs. We
>     met this issue when we set IMAGE_INSTALL = "recipe_name",
>     but we don't have the package with that name.
> 
> I think what I do is to fix the situation 2.
> 
> Further more, we should add checking at the package generating
> time, if the package *with recipe name* was empty and not created,
> trigger a warn and according the warn, we could fix the issue recipes.

The docs say that IMAGE_INSTALL is for "package_name". So I think it's
correct that it fails when you put "recipe_name" in it and sometimes
there isn't any package with the same name. It's the same as trying to
make RDEPENDS/DEPENDS entries to be interchangeable (putting
recipe_names to RDEPENDS and package_names to DEPENDS)."

Especially with that patch for xinput-pointercal, if user explicitly
asks for installing xinput-pointercal, what's the reason to create him
completely empty package? IMHO it's only hiding that issue from him and
instead of discovering the issue in do_rootfs task, he has to check
generated rootfs or even boot the device.

> We already have that checking at the package generating time,
> but it a note, not warn. I suggest we should use warn instead.
> 
> //Hongxu
> 

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

[Hongxu Jia]

On 11/10/2014 02:42 PM, Martin Jansa wrote:
> The docs say that IMAGE_INSTALL is for "package_name". So I think it's
> correct that it fails when you put "recipe_name" in it and sometimes
> there isn't any package with the same name. It's the same as trying to
> make RDEPENDS/DEPENDS entries to be interchangeable (putting
> recipe_names to RDEPENDS and package_names to DEPENDS)."
>
> Especially with that patch for xinput-pointercal, if user explicitly
> asks for installing xinput-pointercal, what's the reason to create him
> completely empty package? IMHO it's only hiding that issue from him and
> instead of discovering the issue in do_rootfs task, he has to check
> generated rootfs or even boot the device.

For most recipes, they generate packages with recipe name, it is not
convenience to figure out the different between package_name and
recipe_name, especially for newbies, which I means we should reduce
that convenience, build relationship between recipe and package,
especially when the recipe doesn't generate the same name package.

As you said, for specific recipes, we don't want to generate packages,
it doesn't make sense to install it by setting IMAGE_INSTALL. But if the
recipe generate packages, it is reasonable to take one with recipe
name, take python3 for example, it choose python-core as the provider.

That's why I sent patch for avahi and oprofileui. The avahi didn't generate
package avahi, but it is reasonable to choose avahi-daemon, as the
SUMMARY said it is a IPv4 configuration daemon.

For oprofileui, it only generates package oprofileui-viewer, if we have
oprofileui as its nick name, I think it is more convenience for the users.

//Hongxu

Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

[Koen Kooi]

> Op 10 nov. 2014, om 08:35 heeft Hongxu Jia <hongxu.jia@windriver.com> het volgende geschreven:
> 
> On 11/10/2014 02:42 PM, Martin Jansa wrote:
>> The docs say that IMAGE_INSTALL is for "package_name". So I think it's
>> correct that it fails when you put "recipe_name" in it and sometimes
>> there isn't any package with the same name. It's the same as trying to
>> make RDEPENDS/DEPENDS entries to be interchangeable (putting
>> recipe_names to RDEPENDS and package_names to DEPENDS)."
>> 
>> Especially with that patch for xinput-pointercal, if user explicitly
>> asks for installing xinput-pointercal, what's the reason to create him
>> completely empty package? IMHO it's only hiding that issue from him and
>> instead of discovering the issue in do_rootfs task, he has to check
>> generated rootfs or even boot the device.
> 
> For most recipes, they generate packages with recipe name, it is not
> convenience to figure out the different between package_name and
> recipe_name, especially for newbies, which I means we should reduce
> that convenience, build relationship between recipe and package,
> especially when the recipe doesn't generate the same name package.

It is not a bug when recipe foo.bb doesn't generate foo.ipk. Your changes introduce needless churn and break upgrade paths only to cater to people making wrong assumptions.

Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

[Hongxu Jia]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

On 11/11/2014 05:02 PM, Koen Kooi wrote:
> It is not a bug when recipe foo.bb doesn't generate foo.ipk. Your changes introduce needless churn and break upgrade paths only to cater to people making wrong assumptions.

Except on purpose to not generate recipe_name package, the other
situation is indeed a bug, such as ssmping and pimd, it don't generate
any package at all.

http://cgit.openembedded.org/meta-openembedded/commit/?id=4b6970c24c3fb0926fd700678c0e11de43a5bf92
http://cgit.openembedded.org/meta-openembedded/commit/?id=c5398fc0fe246e4828c9e950f779f437266bfaa1

If the "Your chagnes" means add checking about the non-create
package, I think you are right, many recipe don't want generate
recipe_name package on purpose, we should avoid that noisy
warning, maybe we should add a script to do that on the result of
world build.

But if the "Your chagnes" means the above fix, I think these fixes is
reasonable for users, especially for newbies. (Actually the issues
were reported by our customer)

//Hongxu


[-- Attachment #2: Type: text/html, Size: 2052 bytes --]

[PATCH 2/4] oprofileui: use oprofileui-viewer as oprofileui's provider

[Hongxu Jia]

The package oprofileui does not exist, so we use oprofileui-viewer as
the provider. It avoids the do_rootfs failure while IMAGE_INSTALL +=
"oprofileui"

Use ${PN} to instead of the hardcoded oprofileui.

[YOCTO #6937]

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
 meta/recipes-kernel/oprofile/oprofileui_git.bb | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/oprofile/oprofileui_git.bb b/meta/recipes-kernel/oprofile/oprofileui_git.bb
index bb69d54..ed6ab93 100644
--- a/meta/recipes-kernel/oprofile/oprofileui_git.bb
+++ b/meta/recipes-kernel/oprofile/oprofileui_git.bb
@@ -11,7 +11,8 @@ SRC_URI = "git://git.yoctoproject.org/oprofileui"
 
 EXTRA_OECONF += "--enable-client --disable-server"
 
-PACKAGES =+ "oprofileui-viewer"
+PACKAGES =+ "${PN}-viewer"
+RPROVIDES_${PN}-viewer = "${PN}"
 
-FILES_oprofileui-viewer = "${bindir}/oparchconv ${bindir}/oprofile-viewer ${datadir}/applications/ ${datadir}/oprofileui/ ${datadir}/icons"
-RDEPENDS_oprofileui-viewer = "oprofile"
+FILES_${PN}-viewer = "${bindir}/oparchconv ${bindir}/oprofile-viewer ${datadir}/applications/ ${datadir}/oprofileui/ ${datadir}/icons"
+RDEPENDS_${PN}-viewer = "oprofile"
-- 
1.9.1

Re: [PATCH 2/4] oprofileui: use oprofileui-viewer as oprofileui's provider

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 302 bytes --]

On 7 November 2014 07:57, Hongxu Jia <hongxu.jia@windriver.com> wrote:

> The package oprofileui does not exist, so we use oprofileui-viewer as
> the provider. It avoids the do_rootfs failure while IMAGE_INSTALL +=
> "oprofileui"
>

Erm, meta/recipes-kernel/oprofile/oprofileui_git.bb?

Ross

[-- Attachment #2: Type: text/html, Size: 824 bytes --]

Re: [PATCH 2/4] oprofileui: use oprofileui-viewer as oprofileui's provider

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

On 7 November 2014 12:06, Burton, Ross <ross.burton@intel.com> wrote:

> On 7 November 2014 07:57, Hongxu Jia <hongxu.jia@windriver.com> wrote:
>
>> The package oprofileui does not exist, so we use oprofileui-viewer as
>> the provider. It avoids the do_rootfs failure while IMAGE_INSTALL +=
>> "oprofileui"
>>
>
> Erm, meta/recipes-kernel/oprofile/oprofileui_git.bb
>

Sorry, my mistake at not reading properly.

Looks like a better fix would be to fix the packaging and provide the old
name for compatibility.

Ross

[-- Attachment #2: Type: text/html, Size: 1414 bytes --]

Re: [PATCH 2/4] oprofileui: use oprofileui-viewer as oprofileui's provider

[Hongxu Jia]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

On 11/07/2014 10:47 PM, Burton, Ross wrote:
>
> On 7 November 2014 12:06, Burton, Ross <ross.burton@intel.com 
> <mailto:ross.burton@intel.com>> wrote:
>
>     On 7 November 2014 07:57, Hongxu Jia <hongxu.jia@windriver.com
>     <mailto:hongxu.jia@windriver.com>> wrote:
>
>         The package oprofileui does not exist, so we use
>         oprofileui-viewer as
>         the provider. It avoids the do_rootfs failure while
>         IMAGE_INSTALL +=
>         "oprofileui"
>
>
>     Erm, meta/recipes-kernel/oprofile/oprofileui_git.bb
>     <http://oprofileui_git.bb>
>
>
> Sorry, my mistake at not reading properly.
>
> Looks like a better fix would be to fix the packaging and provide the 
> old name for compatibility.
>

You mean refer [PATCH 1/4] avahi, change the ${PN}-viewer to PN (which 
rprovides
${PN}-viewer for compatibility)?

Or I don't understand what  'fix the packaging' mean, modify 
package.bbclass?

//Hongxu


> Ross


[-- Attachment #2: Type: text/html, Size: 3146 bytes --]

[PATCH 3/4] pointercal-xinput: add the missing ALLOW_EMPTY

[Hongxu Jia]

Since the do_install conditionally install file if it has a contents,
it should allow the package empty.

It avoids the do_rootfs failure while IMAGE_INSTALL += "pointercal-xinput"

[YOCTO #6937]

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
 meta/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bb b/meta/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bb
index 65348c3..ebc5155 100644
--- a/meta/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bb
+++ b/meta/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bb
@@ -16,5 +16,6 @@ do_install() {
     fi
 }
 
+ALLOW_EMPTY_${PN} = "1"
 PACKAGE_ARCH = "${MACHINE_ARCH}"
 CONFFILES_${PN} = "${sysconfdir}/pointercal.xinput"
-- 
1.9.1

Re: [PATCH 3/4] pointercal-xinput: add the missing ALLOW_EMPTY

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

On Fri, Nov 07, 2014 at 03:57:03PM +0800, Hongxu Jia wrote:
> Since the do_install conditionally install file if it has a contents,
> it should allow the package empty.
> 
> It avoids the do_rootfs failure while IMAGE_INSTALL += "pointercal-xinput"

It was removed intentionally

http://git.openembedded.org/meta-openembedded/commit/?id=9477e53e8a8ffde17b558ac436550687db4b86a0

> [YOCTO #6937]
> 
> Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
> ---
>  meta/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bb | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bb b/meta/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bb
> index 65348c3..ebc5155 100644
> --- a/meta/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bb
> +++ b/meta/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bb
> @@ -16,5 +16,6 @@ do_install() {
>      fi
>  }
>  
> +ALLOW_EMPTY_${PN} = "1"
>  PACKAGE_ARCH = "${MACHINE_ARCH}"
>  CONFFILES_${PN} = "${sysconfdir}/pointercal.xinput"
> -- 
> 1.9.1
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

[PATCH 4/4] postinst-intercept: rename recipe for nativesdk only

[Hongxu Jia]

The recipe postinst-intercept is only used for nativesdk, so we rename
it from postinst-intercept to nativesdk-postinst-intercept.

It avoids unnecessary build of postinst-intercept.

[YOCTO #6937]

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
 ...ostinst-intercept_1.0.bb => nativesdk-postinst-intercept_1.0.bb} | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-devtools/postinst-intercept/{postinst-intercept_1.0.bb => nativesdk-postinst-intercept_1.0.bb} (83%)

diff --git a/meta/recipes-devtools/postinst-intercept/postinst-intercept_1.0.bb b/meta/recipes-devtools/postinst-intercept/nativesdk-postinst-intercept_1.0.bb
similarity index 83%
rename from meta/recipes-devtools/postinst-intercept/postinst-intercept_1.0.bb
rename to meta/recipes-devtools/postinst-intercept/nativesdk-postinst-intercept_1.0.bb
index 41b9a6e..7dc45c6 100644
--- a/meta/recipes-devtools/postinst-intercept/postinst-intercept_1.0.bb
+++ b/meta/recipes-devtools/postinst-intercept/nativesdk-postinst-intercept_1.0.bb
@@ -2,12 +2,12 @@ SUMMARY = "Postinstall scriptlets"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
 
-FILES_${PN}_append_class-nativesdk = " ${datadir}/postinst-intercepts/*"
+FILES_${PN}_append = " ${datadir}/postinst-intercepts/*"
 
 do_configure[noexec] = "1"
 do_compile[noexec] = "1"
 
-do_install_append_class-nativesdk() {
+do_install() {
 	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/
@@ -15,5 +15,5 @@ do_install_append_class-nativesdk() {
 	install -m 755 ${COREBASE}/scripts/postinst-intercepts/update_pixbuf_cache ${D}${datadir}/postinst-intercepts/
 }
 
-BBCLASSEXTEND = "nativesdk"
+inherit nativesdk
 INHIBIT_DEFAULT_DEPS = "1"
-- 
1.9.1

Re: [PATCH 4/4] postinst-intercept: rename recipe for nativesdk only

[Andreas Müller]

On Fri, Nov 7, 2014 at 9:27 AM, Hongxu Jia <hongxu.jia@windriver.com> wrote:
> On 11/07/2014 04:18 PM, Andreas Müller wrote:
>>
>> On Fri, Nov 7, 2014 at 8:57 AM, Hongxu Jia <hongxu.jia@windriver.com>
>> wrote:
>>>
>>> The recipe postinst-intercept is only used for nativesdk, so we rename
>>> it from postinst-intercept to nativesdk-postinst-intercept.
>>>
>>> It avoids unnecessary build of postinst-intercept.
>>>
>>> [YOCTO #6937]
>>>
>>> Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
>>> ---
>>>   ...ostinst-intercept_1.0.bb => nativesdk-postinst-intercept_1.0.bb} | 6
>>> +++---
>>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>>   rename
>>> meta/recipes-devtools/postinst-intercept/{postinst-intercept_1.0.bb =>
>>> nativesdk-postinst-intercept_1.0.bb} (83%)
>>>
>>> diff --git
>>> a/meta/recipes-devtools/postinst-intercept/postinst-intercept_1.0.bb
>>> b/meta/recipes-devtools/postinst-intercept/nativesdk-postinst-intercept_1.0.bb
>>> similarity index 83%
>>> rename from
>>> meta/recipes-devtools/postinst-intercept/postinst-intercept_1.0.bb
>>> rename to
>>> meta/recipes-devtools/postinst-intercept/nativesdk-postinst-intercept_1.0.bb
>>> index 41b9a6e..7dc45c6 100644
>>> --- a/meta/recipes-devtools/postinst-intercept/postinst-intercept_1.0.bb
>>> +++
>>> b/meta/recipes-devtools/postinst-intercept/nativesdk-postinst-intercept_1.0.bb
>>> @@ -2,12 +2,12 @@ SUMMARY = "Postinstall scriptlets"
>>>   LICENSE = "MIT"
>>>   LIC_FILES_CHKSUM =
>>> "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
>>>
>>> -FILES_${PN}_append_class-nativesdk = " ${datadir}/postinst-intercepts/*"
>>> +FILES_${PN}_append = " ${datadir}/postinst-intercepts/*"
>>>
>>>   do_configure[noexec] = "1"
>>>   do_compile[noexec] = "1"
>>>
>>> -do_install_append_class-nativesdk() {
>>> +do_install() {
>>>          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/
>>> @@ -15,5 +15,5 @@ do_install_append_class-nativesdk() {
>>>          install -m 755
>>> ${COREBASE}/scripts/postinst-intercepts/update_pixbuf_cache
>>> ${D}${datadir}/postinst-intercepts/
>>>   }
>>>
>>> -BBCLASSEXTEND = "nativesdk"
>>> +inherit nativesdk
>>>   INHIBIT_DEFAULT_DEPS = "1"
>>> --
>>> 1.9.1
>>>
>> is it possible that the commit message does not match to the patch?
>
>
> You mean the patch doesn't match with cover letter or the patch's commit
> message?
>
> Rename it is to avoid to install postinst-intercept, that will let build
> postinst-intercept
> invalid at parsing time rather than failed at image's do_root.
>
> //Hongxu
>
>
Aargh - I did not read the patch properly - should learn not to write
coffee-less comments

Andreas