All of lore.kernel.org
 help / color / mirror / Atom feed
From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [RFC] recipes/images/${distro}
Date: Sun, 28 Feb 2010 21:09:43 +0100	[thread overview]
Message-ID: <hmeii7$q7e$1@dough.gmane.org> (raw)
In-Reply-To: <1267306071.9295.1.camel@trini-m4400>

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

On 27-02-10 22:27, Tom Rini wrote:
> On Sat, 2010-02-27 at 20:46 +0000, Phil Blundell wrote:
>> On Sat, 2010-02-27 at 16:56 +0000, Graeme Gregory wrote:
>>> NAK on creating extra levels.
>>>
>>> Changing the level where recipes are held is not an option do to the way
>>> you tell bitbake how to find them.
>>>
>>> BBFILES = "${OE}/org.openembedded.dev/recipes/*/*.bb"
>>
>> Is that really such a big deal?  We seemed to manage to switch BBFILES
>> from /packages/ to /recipes/ without any major casualties, and I would
>> have thought that adding an extra level in there would be equally
>> straightforward.  Or of course, even better, the distro-specific recipes
>> could go in an overlay which the distro config would select.
> 
> I think you've just hit on a potentially great idea.  Say that
> 'openembedded' supports 'micro' and 'minimal' as two example
> distributions.  Move everyone else into their own distro overlay.  The
> only problem with this, perhaps, is easily adding the distro overlay
> itself into the right env vars. :(

Move every distro out of OE, that way people need to set the overlays
correctly.

This does mean that we abandon the "sharing" aspect that started OE
since every little "improvement" will be done in the distro overlay
instead of OE.

Maybe the u-boot custodian model would make sense for that type of scenario.

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

iD8DBQFLis2HMkyGM64RGpERAgR2AJ9/q3Xc9iYXzOnmE1DOvameXej0dACeO8eN
3CVU85QKVuinvK4wmN0c+lk=
=q0y3
-----END PGP SIGNATURE-----




  reply	other threads:[~2010-02-28 20:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-27 15:25 [RFC] recipes/images/${distro} Frans Meulenbroeks
2010-02-27 16:38 ` Marco Cavallini
2010-02-27 16:56 ` Graeme Gregory
2010-02-27 17:21   ` Frans Meulenbroeks
2010-02-27 17:38     ` Martin Jansa
2010-02-27 18:04     ` Marcin Juszkiewicz
2010-02-27 18:40       ` Frans Meulenbroeks
2010-02-27 18:45         ` Marcin Juszkiewicz
2010-02-27 19:01           ` Frans Meulenbroeks
2010-02-27 20:11             ` Michael 'Mickey' Lauer
2010-03-03 13:03         ` Otavio Salvador
2010-02-27 20:46   ` Phil Blundell
2010-02-27 21:27     ` Tom Rini
2010-02-28 20:09       ` Koen Kooi [this message]
2010-02-28 20:29         ` Frans Meulenbroeks
2010-03-01 16:05         ` Tom Rini
2010-03-01 16:42           ` Philip Balister
2010-02-28  3:34     ` Graeme Gregory
2010-02-28  4:04       ` Tom Rini
2010-02-28  9:46         ` Frans Meulenbroeks
2010-03-01 20:53       ` Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='hmeii7$q7e$1@dough.gmane.org' \
    --to=k.kooi@student.utwente.nl \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.