[OE-core] [PATCH] usbinit, weston-init, run-postinsts, qt-demo-init: Drop allarch

Martin Jansa martin.jansa at gmail.com
Mon Jun 23 12:44:37 UTC 2014


On Mon, Jun 23, 2014 at 02:39:22PM +0200, Martin Jansa wrote:
> On Mon, Jun 23, 2014 at 01:12:25PM +0100, Burton, Ross wrote:
> > On 19 June 2014 14:54, Paul Eggleton <paul.eggleton at linux.intel.com> wrote:
> > >> * update-rc.d.bbclass now adds dependency on TUNE_PKGARCH initscripts, so
> > >> these cannot be allarch
> > >
> > > As I've said before, I really dislike this change. The system should be made
> > > to handle the situation properly instead of working around the issue.
> > 
> > Isn't this what the abi exclude thingy is for?
> 
> Do we want to maintain list of all recipes which inherit update-rc.c in
> layer.conf?
> 
> That's what I did in one of our layers and the list is rather long.

Ah sorry for possible confusion, I had to list *all* of them because we
have MACHINE_ARCH initscripts.

To fix current issues in oe-core we only need to list all recipes which
inherit allarch *and* update-rc.d (unless we want to exclude it
everywhere just for consistency).

> abi exclude thingy

is a bit dangerous, I still sometimes see issues when something is
supposed to be abisafe and in some cases it isn't and I need to manually
bump PR in the recipe which wasn't rebuilt.

So I'm trying to use SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS only in cases where
it's really safe or when the dependent recipe takes forever to build (so
I wan't to build it just once or once per TUNE_PKGARCH). For simple and
quickly built recipe I really don't mind "building" them multiple times
if it prevents "rebuilding" them every single time I change MACHINE.

-- 
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/20140623/ca68e581/attachment-0002.sig>


More information about the Openembedded-core mailing list