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.ja...@gmail.com
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core