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

[Martin Jansa]

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")

Cheers,

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

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120418/c1e5712c/attachment-0002.sig>