[OE-core] [oe] [meta-oe][PATCH] bash-completion: remove allarch
Martin Jansa
martin.jansa at gmail.com
Fri Mar 7 18:28:58 UTC 2014
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 at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140307/bdb2dae1/attachment-0002.sig>
More information about the Openembedded-core
mailing list