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