[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