[oe] [oe-commits] org.oe.dev rootfs_ipk: as per OE, policy: remove feed management tools
koen at dominion.kabel.utwente.nl
Sun Mar 4 09:43:42 CET 2007
-----BEGIN PGP SIGNED MESSAGE-----
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
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?
PS: Now I think of it, not using TARGET_VENDOR breaks host = target situations....
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
-----END PGP SIGNATURE-----
More information about the Openembedded-devel