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

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Purdie schreef:
> On Fri, 2007-03-02 at 10:47 +0100, Koen Kooi wrote:

>> Again: the ability to use deploy as a feed is still present, it only moved to subdirectories.
>
> Which changed a behaviour people were relying on.
>
> My view on this is currently that:
>
> * Being able to use tmp/deploy/ipk as a feed is a useful feature
> * we should continue to allow that (as developer use only, not for
> building real feeds off)

Sure, but people wanting that can do 'bitbake -b contrib/oe-ipkg-feed.bb'. Building a feed
not used for rootfs assembling during do_rootfs is plain wrong. Can we at least agree on
it being out of scope for do_rootfs?

> Since a number of people want the older single feed behaviour, I think
> we should have some way of allowing that.

'bitbake -b contrib/oe-ipkg-feed.bb' which is only a few chars more as 'bitbake
package-index'. Same amount of commands and 'post-processing'

> I understand why people want
> the split feed behaviour too and we should allow people to select that
> too. Which should be default I don't really care about.

People keep saying that do_rootfs should build a feed that can be used as a feed, but what
is the point in that? OE builds only stuff that's put in the images, so the feed would
almost be a 1:1 copy of the image you install on your device. If you start building more
packages and run do_rootfs again you're getting into the territory of what you called
"long standing distro feeds" and associated bugs.

Think about the situation for a moment:

* OE builds packages and puts those somewhere
* OE uses said packages to make a rootfs

As a side effect you get something you could use a feed after do_rootfs has run.
Or you ran manually ran 'bitbake package-index'.

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.

However, there is one thing that breaks, which is the upload scripts people were using. My
suggestion that scripts can be changed didn't go over to well, so I don't have a solution
for that.

I don't disagree with having a way in OE to generate a feed out of the contents in
deploy/, but given the problems raised OE should make clear you'll have no warranty and it
will eat your dog. What about having an OE way that creates 'deploy/bogofeed', in the
spirit of linux' bogomips?

regards,

Koen

PS: Now I think of it, not using TARGET_VENDOR breaks host = target situations....

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFF6oa+MkyGM64RGpERAmotAJ0ZG5yAEwSgnHmnYSWo06gSPIUGIwCgmZWV
LgJLBfxNp9e1y6A1ipfti7M=
=D0Av
-----END PGP SIGNATURE-----