Re: [PATCH 7/7] allarch: Drop various problematic allarch usages

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2013-04-15 at 10:16 -0500, Mark Hatle wrote:
> On 4/15/13 6:07 AM, Richard Purdie wrote:
> > In each of these cases allarch is used where the package in question has a
> > dependency on things which are not allach and change when MACHINE is changed.
> >
> > This leads to a rebuild of the package each time MACHINE is switched and
> > the sstate checksum changes. The dependencies in question are not suited
> > be being marked as ABISAFE.
> 
> In each of these cases, does the contents of the package change when the MACHINE 
> (or something in that machine) are modified?  If so, I agree they are definitely 
> not allarch.

The contents does not, the sstate checksum however does due to the
dependencies. The dependencies are thinks like gtk+ and dbus.

> However, if the dependency really doesn't matter, then why isn't ABISAFE correct 
> in each case?

I'm using ABISAFE in this context as shorthand for
SIGGEN_EXCLUDERECIPES_ABISAFE and those are defined as things which
don't need to rebuild if the dependency changes.

gtk+ and dbus both provide libraries and we do want software to rebuild
if they change. In the allarch case we could whitelist the dependency
however in the general case we shouldn't.

Even with that problem addressed somehow, it leaves an issue with ipk
multilibs where the distcc-config allarch recipe would always depend
upon "distcc" and hence distcc would get pulled into the image,
regardless of any other multilib settings (which in turn pulls in gtk+
for example). A "lib64-xxx-image" would therefore end up with near
enough two copies of half the system due to this. This is something we
really need to fix in the opkg implementation of multilibs but I have no
idea how.

Combine the two issues together, neither of which can be addressed at
this point of the release cycle and I put the above patch forwards until
we can better resolve this.

Cheers,

Richard