[OE-core] [PATCH] archiver.bbclass: Archive the native builds as well

[Richard Purdie]

On Sat, 2013-01-19 at 09:44 +0100, Holger Hans Peter Freyther wrote:
> On Fri, Jan 18, 2013 at 10:25:43AM -0800, Saul Wold wrote:
> > 
> > I understand what the issue is here, but I am not sure this is the
> > right solution. This will likely bring in way more than is wanted or
> > needed for source archiving.
> > 
> > What's needed from the opkg-utils-native?
> 
> IANAL so let me say it is company/personal policy to release more than
> would be the minimumm specially to avoid corner cases like we have with
> gcc/libgcc.
> 
> I think there are some issues..
> 
> a.) Missing option to tarball everything. I can prepare a patch for that.
> 
> b.) At least libgcc sources not being present.
> 
> c.) How can I get back to compliance? I would have to use something like
> the old DISTRO_PR after I patched the archiver class and rebuild everything.
> How can this be handled today? I have installations in the field that I
> want to upgrade, so the PR of each package should increase.
> 
> d.) Verify that for the meta-toolchain target the necessary GCC sources
> are archived.
> 
> cheers
> 	holger
> 
> PS: Re-sent from the right address

>From a technical perspective, I think gcc could be breaking for two
reasons:

a) It uses the "shared sources" functionality so there is one ${S}
directory for all the different targets. I'm not sure if the archiver
class interacts well with that.

b) libgcc is a "stub" recipe which packages pieces built by a cross
recipe and stashed in the sysroot. The recipe is important as it is a
"target" recipe rather than the other cross recipes.

I'm not sure how removing "native" from the class helps either of these
two things though. Its not like we have a gcc-native or a libgcc-native.

So there could well be a problem here but I'm not feeling happy we've
solved it yet. More information would be appreciated.

Cheers,

Richard