From: Andreas Oberritter <obi@opendreambox.org>
To: openembedded-core@lists.openembedded.org
Subject: Re: MIPS vs MIPS32 tunings -- summary and questions
Date: Wed, 18 Apr 2012 16:37:50 +0200 [thread overview]
Message-ID: <4F8ED1BE.8010109@opendreambox.org> (raw)
In-Reply-To: <1334753155.24091.84.camel@ted>
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.
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
next prev parent reply other threads:[~2012-04-18 14:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-10 17:53 MIPS vs MIPS32 tunings -- summary and questions Mark Hatle
2012-04-10 19:28 ` Andreas Oberritter
2012-04-16 13:55 ` Andreas Oberritter
2012-04-16 14:37 ` Robert Yang
2012-04-16 15:23 ` Andreas Oberritter
2012-04-16 15:50 ` Richard Purdie
2012-04-16 14:42 ` Richard Purdie
2012-04-16 15:15 ` Andreas Oberritter
2012-04-16 15:30 ` Mark Hatle
2012-04-18 11:30 ` Andreas Oberritter
2012-04-18 11:40 ` Richard Purdie
2012-04-18 11:45 ` Andreas Oberritter
2012-04-18 11:53 ` Andreas Oberritter
2012-04-18 11:54 ` Martin Jansa
2012-04-18 12:00 ` Richard Purdie
2012-04-18 12:08 ` Andreas Oberritter
2012-04-18 12:45 ` Richard Purdie
2012-04-18 14:37 ` Andreas Oberritter [this message]
2012-04-18 15:21 ` Mark Hatle
2012-04-18 15:46 ` Martin Jansa
2012-04-18 17:01 ` Koen Kooi
2012-04-18 18:10 ` Andreas Oberritter
2012-04-18 18:31 ` Koen Kooi
2012-04-18 19:57 ` Martin Jansa
2012-04-18 12:15 ` Koen Kooi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F8ED1BE.8010109@opendreambox.org \
--to=obi@opendreambox.org \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox