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).
>
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox