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

[Martin Jansa]

On Wed, Apr 18, 2012 at 07:01:12PM +0200, Koen Kooi wrote:
> 
> Op 18 apr. 2012, om 17:46 heeft Martin Jansa het volgende geschreven:
> 
> > 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")
> 
> That implies you're exposing feeds straight from OE, which is a bad, bad idea.

I'm rsyncing feed (whole deploy dir) to exposed location only after whole build 
is finished and package-indexes regenerated, so I think I'm quite safe.

-- 
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/b2121a84/attachment-0002.sig>