All of lore.kernel.org
 help / color / mirror / Atom feed
* OpenEmbedded goals?
@ 2009-07-04  7:26 Mart R.
  2009-07-04 14:02 ` Michael Smith
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Mart R. @ 2009-07-04  7:26 UTC (permalink / raw)
  To: openembedded-devel

I have been exploring Ångström and thus OpenEmbedded lately. The
building process works nicely out of the box, but running it on some
low end embedded system is out of the question because it is just too
slow and bloated for my taste. Stripping it down is not an easy job
either as I would have to edit countless of *.bb files.

Knowing that Portage has USE flags I was interested to see why they
haven't been implemented to at least some extent in
BitBake/OpenEmbedded. Having found my answer [1] it still kept nagging
me why have they not at least enabled such USE flags at distribution
level?! Sure one can just create a new repository of metadata, but why
duplicate all that work?

It got me thinking about OE and what it tries to be in general.
"Openembedded offers a best-in-class cross-compile environment. It
allows developers to create a complete Linux Distribution for embedded
systems." - This is what the front page says about OE. In reality it
is straying far from its goal in my opinion. It tries to be a generic
framework for building systems and is a full blown distribution (with
options to have custom branding). And from what I can tell it's far
from being "easy to customize".

What if... What if OE went (back) to being a scaffolding to building
actual distributions? OpenEmbedded could provide:
- Out of the box cross-compile environment to whatever system you can imagine,
- Vanilla *.bb files for distributions to use, so they would not have
to duplicate all that work that has already been put into creating
those rules.
It would also mean scrapping all the distribution configurations out
of OE, doing away with all non-essential patches from the BitBake
recipes, etc.

For those vanilla.bb rules to be most efficient some form of USE flags
could be introduced, that can only be assigned in the distribution
configuration files. That way there will be no binary clashes inside
one distribution, and that distribution can come in many flavors
(mydist, mydist-lite, mydist-very-experimental).

For distribution maintainers it would provide more freedom to do as
they please, however they would not have to worry about every single
package and configuration out there (if those vanilla.bb's are
provided by OE already).

If these things have already been discussed in detail, please don't be
shy to point me to those discussions. Also I might be terribly
misinformed and this is actually how things are done and run already.

Mart

[1] http://projects.linuxtogo.org/pipermail/openembedded-devel/2007-September/002990.html



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: OpenEmbedded goals?
  2009-07-04  7:26 OpenEmbedded goals? Mart R.
@ 2009-07-04 14:02 ` Michael Smith
  2009-07-05 20:40 ` Florian Boor
  2009-07-08  5:20 ` Ricardo Salveti de Araujo
  2 siblings, 0 replies; 4+ messages in thread
From: Michael Smith @ 2009-07-04 14:02 UTC (permalink / raw)
  To: openembedded-devel

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1339 bytes --]

On Sat, 4 Jul 2009, Mart R. wrote:

> I have been exploring Ångström and thus OpenEmbedded lately. The
> building process works nicely out of the box, but running it on some
> low end embedded system is out of the question because it is just too
> slow and bloated for my taste. Stripping it down is not an easy job
> either as I would have to edit countless of *.bb files.

Hi Mart,

If you create an overlay, you can fairly easily tweak individual .bb files 
to strip them down without rewriting the entire recipe.

You can list your overlay dir before the OE recipe dir in COLLECTIONS. Set 
FILESPATHBASE to look in your COLLECTIONS for extra patches and files, 
include amend-recipes.inc from your distro conf, and create amend.inc in 
your overlay for any recipes you want to mangle.

This is what the COLLECTIONS and FILESPATHBASE setting looks like:

http://jrz.cbnco.com/git/?p=toastix/toastix.git;a=blob;f=public/conf/site.conf;h=ee1a6d9ce60f65d37dca293c5c4ded04bbb03ff4;hb=HEAD

amend-recipes.inc:

http://projects.linuxtogo.org/pipermail/openembedded-devel/2009-May/011181.html

An amended recipe:

http://jrz.cbnco.com/git/?p=toastix/toastix.git;a=blob;f=public/recipes/diffutils/amend.inc;h=09b24cf568bea5311c1f0a2d154a710752d4e24e;hb=HEAD

(Don't expect much in that repo to work...)

Mike

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: OpenEmbedded goals?
  2009-07-04  7:26 OpenEmbedded goals? Mart R.
  2009-07-04 14:02 ` Michael Smith
@ 2009-07-05 20:40 ` Florian Boor
  2009-07-08  5:20 ` Ricardo Salveti de Araujo
  2 siblings, 0 replies; 4+ messages in thread
From: Florian Boor @ 2009-07-05 20:40 UTC (permalink / raw)
  To: openembedded-devel

Hi,

Mart R. wrote:
> I have been exploring CEngstrC6m and thus OpenEmbedded lately. The
> building process works nicely out of the box, but running it on some
> low end embedded system is out of the question because it is just too
> slow and bloated for my taste. Stripping it down is not an easy job
> either as I would have to edit countless of *.bb files.

you might want to take a look at the "micro" distribution in OE and its
images. The initrd images are another example for tiny images.

> - Out of the box cross-compile environment to whatever system you can
> - imagine,

> - Vanilla *.bb files for distributions to use, so they would not have
> to duplicate all that work that has already been put into creating
> those rules.
> It would also mean scrapping all the distribution configurations out
> of OE, doing away with all non-essential patches from the BitBake
> recipes, etc.

I don't see a reason to do this. OE summarizes a lot of knowledge about how
to (cross-) build whole distributions. Why should we strip away a part of
this?
I see it takes a while to get along with the complexity of OE.... but would
you be happier with less know how and less examples how to do things
correctly?

Greetings

Florian



-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de
                                        http://www.kernelconcepts.de/en



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: OpenEmbedded goals?
  2009-07-04  7:26 OpenEmbedded goals? Mart R.
  2009-07-04 14:02 ` Michael Smith
  2009-07-05 20:40 ` Florian Boor
@ 2009-07-08  5:20 ` Ricardo Salveti de Araujo
  2 siblings, 0 replies; 4+ messages in thread
From: Ricardo Salveti de Araujo @ 2009-07-08  5:20 UTC (permalink / raw)
  To: openembedded-devel

On Sat, Jul 4, 2009 at 4:26 AM, Mart R.<roosmaa+list@gmail.com> wrote:
> I have been exploring Ångström and thus OpenEmbedded lately. The
> building process works nicely out of the box, but running it on some
> low end embedded system is out of the question because it is just too
> slow and bloated for my taste. Stripping it down is not an easy job
> either as I would have to edit countless of *.bb files.
>
> Knowing that Portage has USE flags I was interested to see why they
> haven't been implemented to at least some extent in
> BitBake/OpenEmbedded. Having found my answer [1] it still kept nagging
> me why have they not at least enabled such USE flags at distribution
> level?! Sure one can just create a new repository of metadata, but why
> duplicate all that work?

You can somehow use the USE flags in current OE, but I don't know if
it's the best way to go.

I know we already have long discussions about it at this mailing list,
but here are some problems that I think we'll have if we go to this
direction:
 - Much more hard to debug and reproduce the errors (need more
community support, and we already have a quite long list of bugs)
 - When you start to differentiate a lot at the current OE code base,
you'll have recipes that are quite long with many different options,
one for each distro or etc. In the end the reuse of the meta data is
not so good, as people start to get more used to add specific changes
than fixing and changing the meta data in a way everyone could use it.

What I see is that the current OE solution seems to be a valid base
meta data (that can be shared and used by everyone, letting the debug
easier), and most of the differentiation going when selecting the
packages and configuration for the distros.

Maybe selecting better the packages and how you use them at your
distro can help you get a better image. Of course, you could also
create overlays for specific changes if you want to change it more
than just the selection of the packages.

Cheers,
-- 
Ricardo Salveti de Araujo



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-07-08  5:32 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-04  7:26 OpenEmbedded goals? Mart R.
2009-07-04 14:02 ` Michael Smith
2009-07-05 20:40 ` Florian Boor
2009-07-08  5:20 ` Ricardo Salveti de Araujo

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.