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

[Martin Jansa]

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

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160107/9eef0fcb/attachment-0002.sig>