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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
