[RFC] recipes/images/${distro}

[RFC] recipes/images/${distro}

[Frans Meulenbroeks]

Dear all,

I  think some restructuring is needed wrt distro's and images
I did some counting and we currently have 32 distro's (ls
conf/distro/*.conf | wc
There are a few semi-dups (micro, minimal and oplinux have regular and
uclibc versions, angstrom has angstrom-2008.1-legacy.conf  and
angstrom-2008.1.conf, slugos has slugos, slugos-native and ucslugc)

also we have 94 images (ls recipes/images/*.bb | wc)
For some of these it is quite obvious for which distro's they are.
Mostly because they are prefixed with the distro name (e.g.nylon,
slugos, openmoko)
but for several others it is less clear. grep -i -l angstromg
recipes/images/*.bb | wc gives 30 but not all of them are angstrom
specific.
E.g. nas-server-image.bb mentions angstrom in the comment but is
distro agnostic.

Also sometimes the names are confusing. We have a minimal distro but
minimal-image.bb is not an image for the minimal distro, but is an
angstrom image.

My proposal is to create distro specific subdirs and move all images
from a distro to that specific subdir
That makes it more insightful what belongs to what.

(alternatively if creating an additional level within images is
considered to be "not a good thing" we could either create directories
like images_${distro} or maybe even just ${distro} where a distro can
keep its stuff).
(or yet alteratively we could prefix the distro specific images with
the name of the distro)

Your opinion is appreciated (and please do express your preference (if
any) for an option (ofc keep-as-is is also possible) or coin another
option)

Frans.

Re: [RFC] recipes/images/${distro}

[Marco Cavallini]

Frans Meulenbroeks ha scritto, Il 27/02/2010 16:25:
> Dear all,
> 
> I  think some restructuring is needed wrt distro's and images
> I did some counting and we currently have 32 distro's (ls
> conf/distro/*.conf | wc
> There are a few semi-dups (micro, minimal and oplinux have regular and
> uclibc versions, angstrom has angstrom-2008.1-legacy.conf  and
> angstrom-2008.1.conf, slugos has slugos, slugos-native and ucslugc)
> 
> also we have 94 images (ls recipes/images/*.bb | wc)
> For some of these it is quite obvious for which distro's they are.
> Mostly because they are prefixed with the distro name (e.g.nylon,
> slugos, openmoko)
> but for several others it is less clear. grep -i -l angstromg
> recipes/images/*.bb | wc gives 30 but not all of them are angstrom
> specific.
> E.g. nas-server-image.bb mentions angstrom in the comment but is
> distro agnostic.
> 
> Also sometimes the names are confusing. We have a minimal distro but
> minimal-image.bb is not an image for the minimal distro, but is an
> angstrom image.
> 
> My proposal is to create distro specific subdirs and move all images
> from a distro to that specific subdir
> That makes it more insightful what belongs to what.
> 

+1 from me

/marco

Re: [RFC] recipes/images/${distro}

[Graeme Gregory]

On Sat, Feb 27, 2010 at 04:25:27PM +0100, Frans Meulenbroeks wrote:
> Dear all,
> 
> I  think some restructuring is needed wrt distro's and images
> I did some counting and we currently have 32 distro's (ls
> conf/distro/*.conf | wc
> There are a few semi-dups (micro, minimal and oplinux have regular and
> uclibc versions, angstrom has angstrom-2008.1-legacy.conf  and
> angstrom-2008.1.conf, slugos has slugos, slugos-native and ucslugc)
> 
> also we have 94 images (ls recipes/images/*.bb | wc)
> For some of these it is quite obvious for which distro's they are.
> Mostly because they are prefixed with the distro name (e.g.nylon,
> slugos, openmoko)
> but for several others it is less clear. grep -i -l angstromg
> recipes/images/*.bb | wc gives 30 but not all of them are angstrom
> specific.
> E.g. nas-server-image.bb mentions angstrom in the comment but is
> distro agnostic.
> 
> Also sometimes the names are confusing. We have a minimal distro but
> minimal-image.bb is not an image for the minimal distro, but is an
> angstrom image.
> 
> My proposal is to create distro specific subdirs and move all images
> from a distro to that specific subdir
> That makes it more insightful what belongs to what.
> 
> (alternatively if creating an additional level within images is
> considered to be "not a good thing" we could either create directories
> like images_${distro} or maybe even just ${distro} where a distro can
> keep its stuff).
> (or yet alteratively we could prefix the distro specific images with
> the name of the distro)
> 
> Your opinion is appreciated (and please do express your preference (if
> any) for an option (ofc keep-as-is is also possible) or coin another
> option)
> 

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"

The other option, angstrom images used to be in recipes/angstrom and we
were asked to move them out so other distros can use them. Id be quite
happy with them to return to angstrom/ as it seems they are not useful
to other distros anyway.

Graeme

Re: [RFC] recipes/images/${distro}

[Frans Meulenbroeks]

2010/2/27 Graeme Gregory <dp@xora.org.uk>:
> On Sat, Feb 27, 2010 at 04:25:27PM +0100, Frans Meulenbroeks wrote:
>> Dear all,
>>
>> I  think some restructuring is needed wrt distro's and images
>> I did some counting and we currently have 32 distro's (ls
>> conf/distro/*.conf | wc
>> There are a few semi-dups (micro, minimal and oplinux have regular and
>> uclibc versions, angstrom has angstrom-2008.1-legacy.conf  and
>> angstrom-2008.1.conf, slugos has slugos, slugos-native and ucslugc)
>>
>> also we have 94 images (ls recipes/images/*.bb | wc)
>> For some of these it is quite obvious for which distro's they are.
>> Mostly because they are prefixed with the distro name (e.g.nylon,
>> slugos, openmoko)
>> but for several others it is less clear. grep -i -l angstromg
>> recipes/images/*.bb | wc gives 30 but not all of them are angstrom
>> specific.
>> E.g. nas-server-image.bb mentions angstrom in the comment but is
>> distro agnostic.
>>
>> Also sometimes the names are confusing. We have a minimal distro but
>> minimal-image.bb is not an image for the minimal distro, but is an
>> angstrom image.
>>
>> My proposal is to create distro specific subdirs and move all images
>> from a distro to that specific subdir
>> That makes it more insightful what belongs to what.
>>
>> (alternatively if creating an additional level within images is
>> considered to be "not a good thing" we could either create directories
>> like images_${distro} or maybe even just ${distro} where a distro can
>> keep its stuff).
>> (or yet alteratively we could prefix the distro specific images with
>> the name of the distro)
>>
>> Your opinion is appreciated (and please do express your preference (if
>> any) for an option (ofc keep-as-is is also possible) or coin another
>> option)
>>
>
> 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"

One could do:
BBFILES = "${OE}/org.openembedded.dev/recipes/*/${DISTRO}/*.bb"
BBFILES += "${OE}/org.openembedded.dev/recipes/*/*.bb"
>
> The other option, angstrom images used to be in recipes/angstrom and we
> were asked to move them out so other distros can use them. Id be quite
> happy with them to return to angstrom/ as it seems they are not useful
> to other distros anyway.

Well my main concern is that the current names are kinda misleading.
I got interested in minimal (the distro) but noticed minimal-image is
not for minimal distro (as I had hoped for).
Moving the recipe to the angstrom dir makes things a little bit
cleaner, but does not resolve the name conflict

(and on a personal note: maybe 25+ angstrom recipes is a little bit
overkill, are these all actually used? )

Frans

Re: [RFC] recipes/images/${distro}

[Martin Jansa]

On Sat, Feb 27, 2010 at 06:21:58PM +0100, Frans Meulenbroeks wrote:
> 2010/2/27 Graeme Gregory <dp@xora.org.uk>:
> > On Sat, Feb 27, 2010 at 04:25:27PM +0100, Frans Meulenbroeks wrote:
> >> Dear all,
> One could do:
> BBFILES = "${OE}/org.openembedded.dev/recipes/*/${DISTRO}/*.bb"
> BBFILES += "${OE}/org.openembedded.dev/recipes/*/*.bb"

images directory doesn't look so messy to me as some other directories
and also image recipes are usually quite easy to read/understand, so
I'm not sure why they need to be moved.

> > The other option, angstrom images used to be in recipes/angstrom and we
> > were asked to move them out so other distros can use them. Id be quite
> > happy with them to return to angstrom/ as it seems they are not useful
> > to other distros anyway.
> 
> (and on a personal note: maybe 25+ angstrom recipes is a little bit
> overkill, are these all actually used? )

even 25+ images seems more usefull to me than ie 19 mesa recipes and 17x
pixman (I already moved few and all libpixman to obsolete).

So from my point of view, image recipes doesn't need so much maintenance
as just pulls some subset of packages, why should someone remove them?

On the other side, additional patches are usually added only to latest,
most used recipe (where they are usually also tested) and older recipes
are just getting dust.

Hmm I'm already a bit off-topic, but nobody replied to my "Policy for moving
 older versions to obsolete" :/.

Regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: [RFC] recipes/images/${distro}

[Marcin Juszkiewicz]

Dnia sobota, 27 lutego 2010 o 18:21:58 Frans Meulenbroeks napisał(a):
> One could do:
> BBFILES = "${OE}/org.openembedded.dev/recipes/*/${DISTRO}/*.bb"
> BBFILES += "${OE}/org.openembedded.dev/recipes/*/*.bb"
 
BBFILES = "${OE}/org.openembedded.dev/recipes/" is supported since I do not 
remember when.

Making extra levels in recipes/ dir was discussed so many times that it makes 
me sad when I see yet another discussion about it which will change nothing.

Images/ directory never had sensible naming. "angstrom-gnome-image" is smaller 
then "angstrom-x-image", x11-image is another version of gpe-image (content is 
other but result is same - user lands in GPE + Matchbox v1). If you want to 
have kind of order there then start creating "frans-really-minimal", "frans-
basic-x11-without-gtk-but-small-as-possible", "frans-x11-gpe-mb1", "frans-x11-
gnome" etc images. 

This directory is dump of recipes created by many developers, some of them are 
probably 5-6 years old. There are many recipes for images outside of our 
repository (like bug-image-production for example or those which generate 1GB 
sized rootfs from Montavista). I have on disk image recipe which generate 
package which I use to generate final image. Etc, ETc, ETC...

So generally I am against moving recipes which mention angstrom to 
recipes/angstrom/ just because they contain 'angstrom' word inside. If I will 
push "umbaumba-magic-image" recipe will you opt for moving it to 
recipes/umbaumba just because I wrote it for my internal-no-one-saw-it-and-
who-knows-does-it-exists-at-all distribution?

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: [RFC] recipes/images/${distro}

[Frans Meulenbroeks]

2010/2/27 Marcin Juszkiewicz <marcin@juszkiewicz.com.pl>:
> Dnia sobota, 27 lutego 2010 o 18:21:58 Frans Meulenbroeks napisał(a):
>> One could do:
>> BBFILES = "${OE}/org.openembedded.dev/recipes/*/${DISTRO}/*.bb"
>> BBFILES += "${OE}/org.openembedded.dev/recipes/*/*.bb"
>
> BBFILES = "${OE}/org.openembedded.dev/recipes/" is supported since I do not
> remember when.
>
> Making extra levels in recipes/ dir was discussed so many times that it makes
> me sad when I see yet another discussion about it which will change nothing.
>
> Images/ directory never had sensible naming. "angstrom-gnome-image" is smaller
> then "angstrom-x-image", x11-image is another version of gpe-image (content is
> other but result is same - user lands in GPE + Matchbox v1). If you want to
> have kind of order there then start creating "frans-really-minimal", "frans-
> basic-x11-without-gtk-but-small-as-possible", "frans-x11-gpe-mb1", "frans-x11-
> gnome" etc images.
>
> This directory is dump of recipes created by many developers, some of them are
> probably 5-6 years old. There are many recipes for images outside of our
> repository (like bug-image-production for example or those which generate 1GB
> sized rootfs from Montavista). I have on disk image recipe which generate
> package which I use to generate final image. Etc, ETc, ETC...
>
> So generally I am against moving recipes which mention angstrom to
> recipes/angstrom/ just because they contain 'angstrom' word inside. If I will
> push "umbaumba-magic-image" recipe will you opt for moving it to
> recipes/umbaumba just because I wrote it for my internal-no-one-saw-it-and-
> who-knows-does-it-exists-at-all distribution?
>

Ah well,
I just wanted to suggest a more sensible and clear naming scheme and
clean up a little bit, but apparently this is not appreciated :-(
(and yes, I also think it makes sense to remove old orphaned unused
5-year-old recipes, but guess I'm alone here too).
Guess I'd better not propose to remove some of those 26 (yes,
twenty-six!) glib recipes (or 8 abiword recipes )
Nevermind.

FM

Re: [RFC] recipes/images/${distro}

[Marcin Juszkiewicz]

Dnia sobota, 27 lutego 2010 o 19:40:32 Frans Meulenbroeks napisał(a):

> I just wanted to suggest a more sensible and clear naming scheme and
> clean up a little bit, but apparently this is not appreciated :-(

> (and yes, I also think it makes sense to remove old orphaned unused
> 5-year-old recipes, but guess I'm alone here too).

The problem is that we do not know who uses them. We can remove ones which no 
one is using or alter them in any way - thats why we are using SCM so users 
can revert any change.

> Guess I'd better not propose to remove some of those 26 (yes,
> twenty-six!) glib recipes (or 8 abiword recipes )

Oh cleanups... Too much things to get cleaned, reorganized etc :(

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: [RFC] recipes/images/${distro}

[Frans Meulenbroeks]

2010/2/27 Marcin Juszkiewicz <marcin@juszkiewicz.com.pl>:
> Dnia sobota, 27 lutego 2010 o 19:40:32 Frans Meulenbroeks napisał(a):
>
>> I just wanted to suggest a more sensible and clear naming scheme and
>> clean up a little bit, but apparently this is not appreciated :-(
>
>> (and yes, I also think it makes sense to remove old orphaned unused
>> 5-year-old recipes, but guess I'm alone here too).
>
> The problem is that we do not know who uses them. We can remove ones which no
> one is using or alter them in any way - thats why we are using SCM so users
> can revert any change.
>
>> Guess I'd better not propose to remove some of those 26 (yes,
>> twenty-six!) glib recipes (or 8 abiword recipes )
>
> Oh cleanups... Too much things to get cleaned, reorganized etc :(
>
Yes and this was a small proposal towards it, but I feel it is not
really appreciated, so I suggest to forget about it.
I'll just move on to activities that I feel are more appreciated.

FM

Re: [RFC] recipes/images/${distro}

[Michael 'Mickey' Lauer]

Am Samstag, den 27.02.2010, 20:01 +0100 schrieb Frans Meulenbroeks:
> 2010/2/27 Marcin Juszkiewicz <marcin@juszkiewicz.com.pl>:
> > Dnia sobota, 27 lutego 2010 o 19:40:32 Frans Meulenbroeks napisał(a):
> >
> >> I just wanted to suggest a more sensible and clear naming scheme and
> >> clean up a little bit, but apparently this is not appreciated :-(
> >
> >> (and yes, I also think it makes sense to remove old orphaned unused
> >> 5-year-old recipes, but guess I'm alone here too).
> >
> > The problem is that we do not know who uses them. We can remove ones which no
> > one is using or alter them in any way - thats why we are using SCM so users
> > can revert any change.
> >
> >> Guess I'd better not propose to remove some of those 26 (yes,
> >> twenty-six!) glib recipes (or 8 abiword recipes )
> >
> > Oh cleanups... Too much things to get cleaned, reorganized etc :(
> >
> Yes and this was a small proposal towards it, but I feel it is not
> really appreciated, so I suggest to forget about it.
> I'll just move on to activities that I feel are more appreciated.

Fwiw, I think it's a good idea and would support that. We have a very
conservative majority in OE though ;)

-- 
:M:

Re: [RFC] recipes/images/${distro}

[Otavio Salvador]

Hello,

2010/2/27 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>

> (and yes, I also think it makes sense to remove old orphaned unused
> 5-year-old recipes, but guess I'm alone here too).
>

You're not alone. :-)

This makes metadata processing faster, easier testing since we ought to deal
with less versions, increase possibility of merging of patches in upstream
since they'd be more up to date and so on.

IMO if someone wants a non-changing distro, stable is there for it. dev
ought to be clean.

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: [RFC] recipes/images/${distro}

[Phil Blundell]

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.

p.

Re: [RFC] recipes/images/${distro}

[Tom Rini]

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. :(

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: [RFC] recipes/images/${distro}

[Koen Kooi]

-----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-----

Re: [RFC] recipes/images/${distro}

[Frans Meulenbroeks]

2010/2/28 Koen Kooi <k.kooi@student.utwente.nl>:
> -----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.

I would expect that most of the recipes would be in the common area
(at least that is what I would encourage)
If people add fixes in their own overlay only, they also cannot
benefit any more from the improvements from others, so there is some
advantage to sharing too.

FM
>
> 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-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC] recipes/images/${distro}

[Tom Rini]

On Sun, 2010-02-28 at 21:09 +0100, k.kooia wrote:
> -----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.

Outside of the OE repo, no.  Outside of "conf/" yes.  And yes, this
would require some re-org, perhaps.  Or perhaps not (and we make
something like contrib/ but, I don't know, I suck at naming).  And yes,
with an updated local.conf.sample, getting the overlay stuff right is
trivial.

But yes, not generically done at all improvements would end up in the
distro overlay until someone wanted to fix it generically.

Think of it this way, it would also make it easier to show how to make a
"custom Angstrom" the right way, rather than cp
conf/distro/angstrom-2008.1.conf conf/distro/mydistro.conf which I have
gathered would be a good thing.

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: [RFC] recipes/images/${distro}

[Philip Balister]

On 03/01/2010 11:05 AM, Tom Rini wrote:
> On Sun, 2010-02-28 at 21:09 +0100, k.kooia wrote:
>> -----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.
>
> Outside of the OE repo, no.  Outside of "conf/" yes.  And yes, this
> would require some re-org, perhaps.  Or perhaps not (and we make
> something like contrib/ but, I don't know, I suck at naming).  And yes,
> with an updated local.conf.sample, getting the overlay stuff right is
> trivial.
>
> But yes, not generically done at all improvements would end up in the
> distro overlay until someone wanted to fix it generically.
>
> Think of it this way, it would also make it easier to show how to make a
> "custom Angstrom" the right way, rather than cp
> conf/distro/angstrom-2008.1.conf conf/distro/mydistro.conf which I have
> gathered would be a good thing.

I am also in the all or nothing camp. If we leave any distro specific 
data in the OE repository, people will continue to copy it and start 
committing it back. Also, by leaving one or two distros in tree, people 
will use them as test cases and catch issues that will impact the out of 
tree distros.

Although there may be some short term pain, I believe this will have 
long term benefits for the project.

Philip

Re: [RFC] recipes/images/${distro}

[Graeme Gregory]

On Sat, Feb 27, 2010 at 08:46:47PM +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 have been talking about using overlays for distros at every OE meetup
since kergoth made it easy to do. So I fully support that idea.

Graeme

Re: [RFC] recipes/images/${distro}

[Tom Rini]

On Sun, 2010-02-28 at 03:34 +0000, Graeme Gregory wrote:
> On Sat, Feb 27, 2010 at 08:46:47PM +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 have been talking about using overlays for distros at every OE meetup
> since kergoth made it easy to do. So I fully support that idea.

This would also move a bunch of the distro overrides into amend.inc
files in the in-tree distro overlay, just like out of tree users.  This
might help encourage problems to be fixed or better dealt with, perhaps.

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: [RFC] recipes/images/${distro}

[Frans Meulenbroeks]

2010/2/28 Tom Rini <tom_rini@mentor.com>:
> On Sun, 2010-02-28 at 03:34 +0000, Graeme Gregory wrote:
>> On Sat, Feb 27, 2010 at 08:46:47PM +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 have been talking about using overlays for distros at every OE meetup
>> since kergoth made it easy to do. So I fully support that idea.
>
> This would also move a bunch of the distro overrides into amend.inc
> files in the in-tree distro overlay, just like out of tree users.  This
> might help encourage problems to be fixed or better dealt with, perhaps.
>
> -

+1

Re: [RFC] recipes/images/${distro}

[Richard Purdie]

On Sun, 2010-02-28 at 03:34 +0000, Graeme Gregory wrote:
> On Sat, Feb 27, 2010 at 08:46:47PM +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 have been talking about using overlays for distros at every OE meetup
> since kergoth made it easy to do. So I fully support that idea.

My layers suggestion for bitbake would make it much easier to enable
this kind of thing for end users too...

Perhaps this would get people testing bitbake master? :)

Cheers,

Richard