Re: MIPS vs MIPS32 tunings -- summary and questions

[Mark Hatle <mark.hatle@windriver.com>]

On 4/18/12 9:37 AM, Andreas Oberritter wrote:
> On 18.04.2012 14:45, Richard Purdie wrote:
>> On Wed, 2012-04-18 at 14:08 +0200, Andreas Oberritter wrote:
>>> On 18.04.2012 14:00, Richard Purdie wrote:
>>>> On Wed, 2012-04-18 at 13:54 +0200, Martin Jansa wrote:
>>>>> I had a lot of those (e.g. because armv7a-vfp-neon was including 20
>>>>> arm*feed.conf variants in /etc/opkg most of them empty - without
>>>>> Packages.gz).
>>>>>
>>>>> So I've added "filter" to distro-feed-configs
>>>>> http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=236aa553bb0f82f741c6edb793e96f421f24f4fa
>>>>> to add only feeds I'm generating (and I also don't want armv5* packages
>>>>> installed on armv7a-vfp-neon target unless user explicitly adds armv5*
>>>>> feed).
>>>>
>>>> This is the better solution. I think we need to get a better default
>>>> feed-config generation mechanism into the core. Distros may still need
>>>> to tweak it but it would be good to share some of the best practises...
>>>
>>> Did you look at the patch? Which default setting of
>>> SUPPORTED_EXTRA_ARCHS do you suggest?
>>
>> I did. I didn't say the above patch was a perfect solution.
>>
>>>   Do you think it's feasible to add
>>> every single downloadable arch to this variable? If a user of my distro
>>> decides to build it for some arm or x86 cpu, should he need to know
>>> which archs to add at this place?
>>
>> This is a place where the build system meets and interfaces with the
>> distro. No one policy in the build system is going to fit every distro's
>> needs, not should we ever aim to so.
>
> At least we should have defaults that actually work for someone. Now we
> don't and considering that distro-feed-configs.bb is the only place
> where PACKAGE_EXTRA_ARCHS is actually used, this would be very easy to
> accomplish. Especially because it worked well by default before Mark
> broke it.

PACKAGE_EXTRA_ARCHS is also used by Zypper, RPM configuration and other places. 
  In those cases it is a full list of all available (and compatible) package 
architecture types.

Coming from the RPM world, it seems very odd to me that a set of "extra_archs" 
can not list well, extra compatible archs without causing an error.  I have no 
idea how to reconcile this behavior, without making a package manager 
distro-feed specific solution.  (For RPM we absolutely want the existing behavior.)

--Mark

> I guess it's indeed better to just override the necessary bits in my
> distro instead of trying to get working defaults upstream.
>
> Regards,
> Andreas
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core