[OE-core] [PATCH 7/7] allarch: Drop various problematic allarch usages

[Mark Hatle]

On 4/15/13 10:40 AM, Richard Purdie wrote:
> 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.

So this can't be set on a package specific basis?  If that is the case, it may 
make sense to look into a recipe specific way of declaring a 'lack' of 
dependency on rebuilding others in the future.

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

Ya I agree, I thought it could be done easily on a per-package basis.

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

This is more then just a problem in opkg, it may be more evident there.. but it 
is something we should look into as well.

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