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

[Koen Kooi]

Op 18 apr. 2012, om 14:00 heeft Richard Purdie het volgende geschreven:

> On Wed, 2012-04-18 at 13:54 +0200, Martin Jansa wrote:
>> On Wed, Apr 18, 2012 at 01:45:54PM +0200, Andreas Oberritter wrote:
>>> On 18.04.2012 13:40, Richard Purdie wrote:
>>>> On Wed, 2012-04-18 at 13:30 +0200, Andreas Oberritter wrote:
>>>>> now, after having repacked all binary tarballs that had mipsel or
>>>>> mipsel-nf in their name and contents, and after having changed all
>>>>> occurrences of mipsel and mipsel-nf in my local recipes (where
>>>>> appropriate), and after having rebuilt everything from scratch again, it
>>>>> came to my attention that "mipsel" in PACKAGE_EXTRA_ARCHS breaks opkg,
>>>>> because no mipsel packages are being generated. That's what I told
>>>>> before, right?
>>>> 
>>>> How is this breaking opkg? We often have architectures listed in there
>>>> for which there are no packages generated (all, noarch and any spring to
>>>> mind)?
>>> 
>>> Downloading http://10.0.0.1/mipsel/Packages.gz.
>>> wget: server returned error: HTTP/1.1 404 Not Found
>>> Collected errors:
>>> * opkg_download: Failed to download http://10.0.0.1/mipsel/Packages.gz, wget returned 1.
>> 
>> 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...

That's exactly why I invented FEED_ARCH a few years ago, which is now changed to BASE_PACKAGE_ARCH. The angstrom-feed-configs recipe which distro-feed-configs was based on doesn't support from the the above drawbacks.
This discussion about using all PACKAGE_*_ARCHS to generate URLs pops up every other year with people concluding that distro-feed-configs sucks.
I can only recommend to have an integrated solution to manage your binary feeds instead of trying to fit it into the (broken) distro-feed-config model.

regards,

Koen