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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.