[OE-core] MIPS vs MIPS32 tunings -- summary and questions

[Koen Kooi]

Op 18 apr. 2012, om 20:10 heeft Andreas Oberritter het volgende geschreven:

> On 18.04.2012 19:01, Koen Kooi wrote:
>> 
>> Op 18 apr. 2012, om 17:46 heeft Martin Jansa het volgende geschreven:
>> 
>>> On Wed, Apr 18, 2012 at 10:21:38AM -0500, Mark Hatle wrote:
>>>> 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.)
>>> 
>>> The problem Andreas is seeing is not fatal AFAIK.. just couple (or a
>>> lot) of 404 (Packages files not available) while doing opkg update is
>>> not nice for end user. 
>>> 
>>> Downloading many existing Packages files without any Package in it
>>> is also suboptimal, but maybe good start.. so we can teach
>>> meta/classes/package_ipk.bbclass:package_update_index_ipk() to create
>>> Packages files not only for existing
>>> ipkgarchs="${ALL_MULTILIB_PACKAGE_ARCHS} ${SDK_PACKAGE_ARCHS}"
>>> but for all (replace "if [ -e $pkgdir/ ]; then" with something like 
>>> "if [ ! -e $pkgdir/ ]; then mkdir -p $pkgdir; fi")
>> 
>> That implies you're exposing feeds straight from OE, which is a bad, bad idea.
> 
> Can you please elaborate on why this is a bad idea?

The main reason is that packages will get recreated with different MD5 sums, upsetting opkg. And worse, they will have different contents because PR bumps get left out a lot (but less than they used to). It's analogous to using WORKDIR/rootfs for nfsroot. It might work for you, but in general it's a bad idea.
What we do in angstrom is disallow duplicate files to get uploaded, so foo_1.0-r0.ipk won't get overwritten by a 'newer' foo_1.0-r0.ipk, it will only go away if foo_1.0-r1.ipk gets uploaded.

regards,

Koen