All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Yang <liezhi.yang@windriver.com>
To: Martin Jansa <martin.jansa@gmail.com>, Phil Blundell <pb@pbcl.net>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 3/3] liberation-fonts: can't be allarch
Date: Wed, 13 Jan 2016 13:56:29 +0800	[thread overview]
Message-ID: <5695E70D.9000501@windriver.com> (raw)
In-Reply-To: <20160107125502.GD2512@jama>


Hi Martin,

Here is a new patch which can fix allarch's mutilib dependencies issues,
can you see any potential problems with this patch, please ?

Subject: [PATCH] multilib.bbclass: extend allarch recipes

Extend allarch recipes, this can fix multilib dependencies issues, for
example:
$ bitbake lib32-run-postinsts
No 64 bit recipes should be built, but the fact was *no 32 bit* recipes
were built, this was because "bitbake lib32-run-postinsts" was the same as
"bitbake run-postinsts" since we didn't extend allarch recipes.

Extend allarch recipes just as allarch packagegroups will fix the
problem.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
  meta/classes/multilib.bbclass        |    4 ----
  meta/classes/multilib_global.bbclass |    4 +---
  meta/classes/package.bbclass         |    6 ------
  3 files changed, 1 insertion(+), 13 deletions(-)

diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 75e91fa..514588e 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -46,10 +46,6 @@ python multilib_virtclass_handler () {
      if bb.data.inherits_class('nativesdk', e.data) or 
bb.data.inherits_class('crosssdk', e.data):
          raise bb.parse.SkipPackage("We can't extend nativesdk recipes")

-    if bb.data.inherits_class('allarch', e.data) and not 
bb.data.inherits_class('packagegroup', e.data):
-        raise bb.parse.SkipPackage("Don't extend allarch recipes which are not 
packagegroups")
-
-
      # Expand this since this won't work correctly once we set a multilib into 
place
      e.data.setVar("ALL_MULTILIB_PACKAGE_ARCHS", 
e.data.getVar("ALL_MULTILIB_PACKAGE_ARCHS", True))

diff --git a/meta/classes/multilib_global.bbclass 
b/meta/classes/multilib_global.bbclass
index 67dc72b..2c115d5 100644
--- a/meta/classes/multilib_global.bbclass
+++ b/meta/classes/multilib_global.bbclass
@@ -143,9 +143,7 @@ python multilib_virtclass_handler_global () {

      if isinstance(e, bb.event.RecipeParsed) and not variant:
          if bb.data.inherits_class('kernel', e.data) or \
-            bb.data.inherits_class('module-base', e.data) or \
-            (bb.data.inherits_class('allarch', e.data) and\
-             not bb.data.inherits_class('packagegroup', e.data)):
+            bb.data.inherits_class('module-base', e.data):
              variants = (e.data.getVar("MULTILIB_VARIANTS", True) or "").split()

              import oe.classextend
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index c51a4e8..697b4d2 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1294,9 +1294,6 @@ python emit_pkgdata() {
      if bb.data.inherits_class('kernel', d) or 
bb.data.inherits_class('module-base', d):
          write_extra_pkgs(variants, pn, packages, pkgdatadir)

-    if (bb.data.inherits_class('allarch', d) and not 
bb.data.inherits_class('packagegroup', d)):
-        write_extra_pkgs(global_variants, pn, packages, pkgdatadir)
-
      workdir = d.getVar('WORKDIR', True)

      for pkg in packages.split():
@@ -1377,9 +1374,6 @@ python emit_pkgdata() {
      if bb.data.inherits_class('kernel', d) or 
bb.data.inherits_class('module-base', d):
          write_extra_runtime_pkgs(variants, packages, pkgdatadir)

-    if bb.data.inherits_class('allarch', d) and not 
bb.data.inherits_class('packagegroup', d):
-        write_extra_runtime_pkgs(global_variants, packages, pkgdatadir)
-
      bb.utils.unlockfile(lf)
  }
  emit_pkgdata[dirs] = "${PKGDESTWORK}/runtime ${PKGDESTWORK}/runtime-reverse 
${PKGDESTWORK}/runtime-rprovides"
-- 
1.7.9.5

// Robert

On 01/07/2016 08:55 PM, Martin Jansa wrote:
> On Thu, Jan 07, 2016 at 12:16:44PM +0000, Phil Blundell wrote:
>> On Wed, 2016-01-06 at 23:45 -0800, Robert Yang wrote:
>>> liberation-fonts inherit fontcache which would depend on fontconfig,
>>> and fontconfig is not allarch, so that liberation-fonts can't be
>>> allarch.
>>
>> This doesn't make any sense.  I don't think allarch is, or ever has
>> been, contagious in that way.  There is no good reason I can think of
>> to require that all the dependencies of an allarch package should
>> themselves be allarch.  Indeed, if we did require this then it would
>> probably mean that virtually no packages could legitimately be allarch.
>
> Current implementation requires that, because if there is dependency on
> TUNE_PKGARCH or MACHINE_ARCH recipe, then this "allarch" recipe will be
> rebuilt (or at least different archive is unpacked from sstate) every
> single time you switch MACHINE.
>
> That's why there is SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS and
> SIGGEN_EXCLUDERECIPES_ABISAFE for sstate code to skip some dependencies
> like this - but that doesn't remove the dependency only says that the
> allarch recipe doesn't need to be rebuilt when the dependency signature
> was modified.
>
> Marking recipe as allarch incorrectly is worse than leaving it
> TUNE_PKGARCH, because as TUNE_PKGARCH it's rebuilt once per architecture
> and the stamps are valid until next metadata change, with incorrect
> allarch it's also rebuilt once per architecture (or MACHINE), but also
> unpacked from sstate every time you change the MACHINE (even when the
> resulting packages end in the same directory with the same filename -
> except when PRservice changes the last number in EXTENDPRAUTO with each
> MACHINE change).
>


  reply	other threads:[~2016-01-13  5:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-07  7:45 [PATCH 0/3] meta: 3 fixes Robert Yang
2016-01-07  7:45 ` [PATCH 1/3] cogl-1.0: fix may be used uninitialized error Robert Yang
2016-01-07  7:45 ` [PATCH 2/3] run-postinsts: can't be allarch Robert Yang
2016-01-07 10:57   ` Richard Purdie
2016-01-08  6:03     ` Robert Yang
2016-01-11  8:27     ` Robert Yang
2016-01-19  9:22     ` Robert Yang
2016-01-07  7:45 ` [PATCH 3/3] liberation-fonts: " Robert Yang
2016-01-07 11:11   ` Martin Jansa
2016-01-07 12:16   ` Phil Blundell
2016-01-07 12:55     ` Martin Jansa
2016-01-13  5:56       ` Robert Yang [this message]
2016-01-13  6:00         ` Robert Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5695E70D.9000501@windriver.com \
    --to=liezhi.yang@windriver.com \
    --cc=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=pb@pbcl.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.