Re: [oe] [meta-oe][PATCH] bash-completion: remove allarch

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]

On Fri, Mar 07, 2014 at 10:09:00AM +0000, Paul Eggleton wrote:
> On Thursday 06 March 2014 20:21:22 Martin Jansa wrote:
> > On Thu, Mar 06, 2014 at 05:59:29PM +0000, Paul Eggleton wrote:
> > > On Thursday 06 March 2014 18:04:50 Martin Jansa wrote:
> > > > * it has runtime dependency on TUNE_PKGARCH bash, so it cannot be
> > > > allarch
> > > 
> > > As we've already discussed this is not universally true. There are other
> > > ways to solve this.
> > 
> > Like making it special case like packagegroups? That is still making me
> > headaches when some library (for some reason) included in packagegroup
> > is renamed thanks to debian.bbclass and packagegroup isn't rebuilt, so
> > it breaks do_rootfs..
> 
> Did you report this? FWIW it's the first I recall hearing of the problem; 
> perhaps I just missed it.

I've discussed this with RP on IRC, but haven't filled the bugzilla
ticket, my fault, will do that later.

> > I would rather build bash-completion only once per architecture than
> > rebuilding it as "allarch" every time I'm building for MACHINE with
> > different TUNE_PKGARCH.
> 
> As I said last time, I'm not arguing that rebuilding allarch recipes on 
> machine change is preferable - obviously it isn't. On the other hand, what 
> you're doing with this kind of change is telling the build system that the 
> recipe needs to be built differently depending on what the target architecture 
> is, which is *not* true; this is only being done to work around the build 
> system making an assumption that the rebuild needs to happen. Fix the 
> assumption and the problem is fixed, properly. 
> 
> If we need to make changes to the core or BitBake to make it easier to handle 
> this properly, by all means let's do that; but if we go down the road of 
> applying the workaround to every recipe where we hit this issue (and as we 
> have seen it's not just one or two recipes) we will never get around to fixing 
> the underlying problem.

What I'm trying to do is to prevent rebuilding them until the
underlaying problem is fixed (which can be tracked in bugzilla with 2
very simple recipes as reproducer).

I don't want this to show in every build and as "known-possitive" in
every sstate-diff-machine.sh call. It's less pain to just rebuild them
once per TUNE_PKGARCH even when they could be allarch.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]