Re: [oe-commits] org.oe.dev rootfs_ipk: as per OE, policy: remove feed management tools

[Matthias Hentges <oe@hentges.net>]

Am Sonntag, den 04.03.2007, 12:31 +0100 schrieb Koen Kooi:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Richard Purdie schreef:
> > On Sun, 2007-03-04 at 09:43 +0100, Koen Kooi wrote:
> 
> >> So it always required an extra command (either 'bitbake <foo>-image' or 'bitbake
> >> package-index'), since the index wasn't refreshed automagically after you built a package.
> > 
> > Nobody has a problem with that.
> 
> People did seem to have problems with that, citing 'needless post processing' when I said
> you need to run one (1) command to get a feed! But we'll from now on assume people have no
> problems with it.

I have no problem running package-index to re(!)-generate a feed. I've
been using package-index for exactly this purpose for a long time.

> > OE is not just about image generation!
> 
> I didn't say that, I meant that people wanting a Packages.* in deploy/ipk _most likely_
> have more packages there than <foo>-image will generate and hence move out of do_rootfs
> territory.

Indeed. As soon as we leave do_rootfs territory, we kinda sorta enter
feed-generation territory, do we not? What good is a truckload of
compiled stuff if you don't have a sane way of installing it.

> FWIW, image generation is ~5% of what I use OE for.
> 
> 
> > I accept there is a fine line between this and supporting feed
> > generation from OE. The thing is people have been happily using that
> > directory as a feed, not for users but for development work. I don't
> > think its fair to break that when we don't need to.
> 
> It didn't break, it _moved_, the subdirectories can still be used as development feeds.
> Instead of saying
> 
> echo 'src/gz devfeed http://buildbox/tmp/deploy/ipk' > /etc/ipkg/devfeed.conf
> 
> you will now say
> 
> echo 'src/gz devfeed1 http://buildbox/tmp/deploy/ipk/ppc603e' > /etc/ipkg/devfeed1.conf
> echo 'src/gz devfeed2 http://buildbox/tmp/deploy/ipk/efika' > /etc/ipkg/devfeed2.conf

Well, it's 3 feeds for slugos and openmo feed. Basically you get
ipk/ARCH, ipk/MACHINE, and ipk/all.

In addition you'll get a bogus empty x86 feed and an empty ipk/Packages
file....

> Right? Or did the cset *really* break that as people keep claiming?

The cset broke the long-used single feed that many of us were using for
years (!) for the sole benefit of the multi-machine guys. Without a way
to revert to the old way.

That's the whole point of this entire thread. I never had a problem with
the change, only the way it has been implemented.

> Assuming the above didn't break, what about this:
> 
> 'bitbake package-index' will generate a deploy/bogofeed, everything else stays as it is now.

My reverted cset did exactly the above, it didn't even so much as touch
your holy new ipk directory.