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

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

[Paul Eggleton]

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

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

[Martin Jansa]

[-- 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 --]

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

[Martin Jansa]

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

On Fri, Mar 07, 2014 at 07:28:58PM +0100, Martin Jansa wrote:
> 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.

https://bugzilla.yoctoproject.org/show_bug.cgi?id=5970

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

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