[OE-core] [PATCH 3/3] liberation-fonts: can't be allarch

Robert Yang liezhi.yang at windriver.com
Wed Jan 13 05:56:29 UTC 2016


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 at 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).
>



More information about the Openembedded-core mailing list