[RFC] get rid of legacy staging

[RFC] get rid of legacy staging

[Frans Meulenbroeks]

Dear all,

The topic of legacy staging has been on the table for probably 8 months or
so.
Still we have a lot of recipes that use legacy staging.
This email tries to stir up the discussion on how to get rid of these.

Most of the major recipes seem to be converted.
Koen reported 53 recipes with legacy staging after building
angstrom-gnome-image and openjdk. [1]
This seems an indication that lots of common and actively used recipes are
converted.
However there are still 1100+ recipes and about 150 .inc files that have a
do_stage rule [2]

This indicates that quite some work is still needed.
Let's have a look at the options. What I see as possibilities are:

A: accept that we will have lots of recipes around that use legacy staging
B: update and test all recipes (at least up to the level that it is verified
that the files stage properly after removing the legacy staging
C: with a sed script or so remove all do_stage functions and hope the best
for it.
D: remove the recipes that still use legacy staging as apparently no-one is
enough interested in them to update them.

Let us now look at the pro's and con's of these possiblities:

From the various calls to fix this that I have seen on the mailing list A is
not really too desired.

B would be nice, but is a hell lot of work. With 1100 recipes, 150 inc files
and 5 minutes per recipe, this takes about 100 hours.
Even with one minute per recipe it would be about 20 hours.
Given that lots of the recipes for which this applies seem to be rarely used
or are older versions of recipes that are not used any more, this seems
somewhat a waste of time.
Unless someone stands up as volunteer or someone develops an automated
solution, I feel this is not going to happen.
(and no: I feel no desire at all to spend hours and hours of my spare time
to convert recipes most of which I am very unlikely to use).

C is a quick hack without warranty that the recipe is not broken.
I've no idea how you feel about this, but in my opinion I'd rather have a
legacy staging recipe which works than a non-legacy staging one which might
or might not be broken.

That leaves option D. Of course removing all recipes that still use legacy
staging is not desired, as that would also mean e.g. removal of the 53
recipes identified by Koen. [1]
However, the idea has some merits. Lots of the recipes with legacy staging
seem to be old recipes. See e.g. the alsa-lib example [3]. By removing these
at least the time and work needed for B would be less.

Now how to proceed?
Well that is the reason for this email.
I would like to hear your opinions on this, so feel free to voice them.
If there is consensus we can start deploying things. If not we might ask the
TSC for some guidance.

To start off the discussion let me give you my personal view.

I would be in favour to remove all recipes that use legacy staging and that
do not fit into one of the following categories:
- it is  the most recent version of the package that is build by the recipe
- it is not the most recent version but all more recent versions have
DEFAULT_PREFERENCE = "-1"
- it is pinned by a distro
- it is a toolchain recipe (gcc, binutils, automake, autoconf and probably
glibc)
- it is a kernel or u-boot recipe
The rationale behind this is that it removes a lot of recipes (and hence a
lot of work converting).
Note that the recipes are not gone. They will remain in the stable 2009
branch and they can always be retrieved from git.
So should someone for whatever reason need a recipe he/she can recover it,
fix it and put it back.

After that we can make an inventory of the work remaining.
If there are relatively few recipes remaining it will become a lot simpler
to find volunteers to clean up those.
If there are many e.g. because an orphaned distro or machine pins lots of
legacy recipes) we might consider a different scenario.

This is my personal view, but ofc I would like to have a discussion on this
and hear other opinions so preferably we can come to a consensus.
The only request I have is that if you advocate a certain solution that you
are willing to participate in realising that solution.
E.g. it is easy to say that B is the desired scenario and that others should
implement this.

Best regards, Frans.

PS: if the consensus is to start off removing the legacy recipes as I
proposed above, I am more than willing to participate in that.
and if someone has a good idea on how to automate identification of
qualifying recipes (especially weeding out from the list, the ones we still
want to retain), I'd love to learn about that too.

[1]
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-July/021870.html
[2]
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-July/021901.html
[3]
http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg08150.html

Re: [RFC] get rid of legacy staging

[Koen Kooi]

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

How about this:

People go out and convert recipes they use/care about and try to fix up
all versions. Once all the build targets people care about are legacy
free (e.g. SHR and angstrom images, meta-toolchain-*), we evaluate the
remaining recipes.
If noone care about the older versions of converted recipes they get
placed in removal.txt with the usual date (iirc a few weeks) and the
list gets posted to the ml. After the date in removal.txt they will get
deleted.
This mean that recipes that noone seems to care about will keep legacy
staging. And I think that's OK, since there are a *lot* of recipes that
"just work" and only get built once a year or so, but are still wanted
by lots of users. I come across recipes like that every week.

What I would hate to see is that people return from summer holiday and
suddenly half of OE has been deleted including usefull, but unpopular stuff.

regards,

Koen



On 24-07-10 11:57, Frans Meulenbroeks wrote:
> Dear all,
> 
> The topic of legacy staging has been on the table for probably 8 months or
> so.
> Still we have a lot of recipes that use legacy staging.
> This email tries to stir up the discussion on how to get rid of these.
> 
> Most of the major recipes seem to be converted.
> Koen reported 53 recipes with legacy staging after building
> angstrom-gnome-image and openjdk. [1]
> This seems an indication that lots of common and actively used recipes are
> converted.
> However there are still 1100+ recipes and about 150 .inc files that have a
> do_stage rule [2]
> 
> This indicates that quite some work is still needed.
> Let's have a look at the options. What I see as possibilities are:
> 
> A: accept that we will have lots of recipes around that use legacy staging
> B: update and test all recipes (at least up to the level that it is verified
> that the files stage properly after removing the legacy staging
> C: with a sed script or so remove all do_stage functions and hope the best
> for it.
> D: remove the recipes that still use legacy staging as apparently no-one is
> enough interested in them to update them.
> 
> Let us now look at the pro's and con's of these possiblities:
> 
> From the various calls to fix this that I have seen on the mailing list A is
> not really too desired.
> 
> B would be nice, but is a hell lot of work. With 1100 recipes, 150 inc files
> and 5 minutes per recipe, this takes about 100 hours.
> Even with one minute per recipe it would be about 20 hours.
> Given that lots of the recipes for which this applies seem to be rarely used
> or are older versions of recipes that are not used any more, this seems
> somewhat a waste of time.
> Unless someone stands up as volunteer or someone develops an automated
> solution, I feel this is not going to happen.
> (and no: I feel no desire at all to spend hours and hours of my spare time
> to convert recipes most of which I am very unlikely to use).
> 
> C is a quick hack without warranty that the recipe is not broken.
> I've no idea how you feel about this, but in my opinion I'd rather have a
> legacy staging recipe which works than a non-legacy staging one which might
> or might not be broken.
> 
> That leaves option D. Of course removing all recipes that still use legacy
> staging is not desired, as that would also mean e.g. removal of the 53
> recipes identified by Koen. [1]
> However, the idea has some merits. Lots of the recipes with legacy staging
> seem to be old recipes. See e.g. the alsa-lib example [3]. By removing these
> at least the time and work needed for B would be less.
> 
> Now how to proceed?
> Well that is the reason for this email.
> I would like to hear your opinions on this, so feel free to voice them.
> If there is consensus we can start deploying things. If not we might ask the
> TSC for some guidance.
> 
> To start off the discussion let me give you my personal view.
> 
> I would be in favour to remove all recipes that use legacy staging and that
> do not fit into one of the following categories:
> - it is  the most recent version of the package that is build by the recipe
> - it is not the most recent version but all more recent versions have
> DEFAULT_PREFERENCE = "-1"
> - it is pinned by a distro
> - it is a toolchain recipe (gcc, binutils, automake, autoconf and probably
> glibc)
> - it is a kernel or u-boot recipe
> The rationale behind this is that it removes a lot of recipes (and hence a
> lot of work converting).
> Note that the recipes are not gone. They will remain in the stable 2009
> branch and they can always be retrieved from git.
> So should someone for whatever reason need a recipe he/she can recover it,
> fix it and put it back.
> 
> After that we can make an inventory of the work remaining.
> If there are relatively few recipes remaining it will become a lot simpler
> to find volunteers to clean up those.
> If there are many e.g. because an orphaned distro or machine pins lots of
> legacy recipes) we might consider a different scenario.
> 
> This is my personal view, but ofc I would like to have a discussion on this
> and hear other opinions so preferably we can come to a consensus.
> The only request I have is that if you advocate a certain solution that you
> are willing to participate in realising that solution.
> E.g. it is easy to say that B is the desired scenario and that others should
> implement this.
> 
> Best regards, Frans.
> 
> PS: if the consensus is to start off removing the legacy recipes as I
> proposed above, I am more than willing to participate in that.
> and if someone has a good idea on how to automate identification of
> qualifying recipes (especially weeding out from the list, the ones we still
> want to retain), I'd love to learn about that too.
> 
> [1]
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-July/021870.html
> [2]
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-July/021901.html
> [3]
> http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg08150.html

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

iD8DBQFMSsSJMkyGM64RGpERAhhNAKC6BmsL13nbL3N4z2iirmtkk6JP6ACguLTo
S6chuyETQHFcfIaiYONuVGY=
=8fwc
-----END PGP SIGNATURE-----

Re: [RFC] get rid of legacy staging

[Frans Meulenbroeks]

2010/7/24 Koen Kooi <k.kooi@student.utwente.nl>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> How about this:
>
> People go out and convert recipes they use/care about and try to fix up
> all versions. Once all the build targets people care about are legacy
> free (e.g. SHR and angstrom images, meta-toolchain-*), we evaluate the
> remaining recipes.
>

That procedure is fine with me, although I must say I feel we already tried
this for half a year or so.

In order for this to work I suggest to add owners to it.
E.g. can people speak up who care about a recipe/distro and who want to work
on getting legacy staging removed for those (because it is easy to say that
one feels that X need to be free of legacy staging and leave it to unnamed
others to resolve it).

I for me, I care about the recipes I've created and/or did substantial
additions to.
As far as I know, these are all free of legacy staging with the exception of
a few perl recipes (where the issue is cpan.bbclass; an issue I hopefully
have resolved and that is compiling as I write this).

If noone care about the older versions of converted recipes they get
> placed in removal.txt with the usual date (iirc a few weeks) and the
> list gets posted to the ml. After the date in removal.txt they will get
> deleted.
>
I'm unaware of a removal policy as you describe (although it does not sound
bad to me).
I

> This mean that recipes that noone seems to care about will keep legacy
> staging. And I think that's OK, since there are a *lot* of recipes that
> "just work" and only get built once a year or so, but are still wanted
> by lots of users. I come across recipes like that every week.
>

I seriously doubt that the recipes that compy to the criteria I gave are
build often. They are not the primary/leading version.
If I do a bake of a recipe and it is not for testing purposes it is
invariably the default version (the latest one taking DEFAULT_PREFERENCE
into account).
I seriously doubt many people will bake old versions (like for example
alsa-lib_1.0.14.bb, a recipe that according to the TSC advisory [4] could
have been deleted quite some time ago)

What I would hate to see is that people return from summer holiday and
> suddenly half of OE has been deleted including usefull, but unpopular
> stuff.
>

That is not my intention. Note that my proposal aimed at always keeping the
most recent version (taking DEFAULT_PREFERENCE into account) of a recipe.
I also object to your choice of wording. The recipes are *not* deleted. They
are still in the stable2009 branch as well as in git.
People who need them can still get them from those places.
They are merely removed from dev head.

On the other hand: if someone cares so much about a recipe it would be nice
if he/she should fix it.

Frans.

PS: did one more grep. From the 1119 recipes that contain the word do_stage
there are 716 differently named recipes (recipes that have the same
basename, so are identical expect wrt the part after the _
So more than 400 recipes are older versions (probably more as there are also
recipes like e.g. alsa-lib that have their latest version fixed, could not
think of a simple way to measure how much of it that is).

[4]
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-May/020047.html

>
> regards,
>
> Koen
>
>
>
> On 24-07-10 11:57, Frans Meulenbroeks wrote:
> > Dear all,
> >
> > The topic of legacy staging has been on the table for probably 8 months
> or
> > so.
> > Still we have a lot of recipes that use legacy staging.
> > This email tries to stir up the discussion on how to get rid of these.
> >
> > Most of the major recipes seem to be converted.
> > Koen reported 53 recipes with legacy staging after building
> > angstrom-gnome-image and openjdk. [1]
> > This seems an indication that lots of common and actively used recipes
> are
> > converted.
> > However there are still 1100+ recipes and about 150 .inc files that have
> a
> > do_stage rule [2]
> >
> > This indicates that quite some work is still needed.
> > Let's have a look at the options. What I see as possibilities are:
> >
> > A: accept that we will have lots of recipes around that use legacy
> staging
> > B: update and test all recipes (at least up to the level that it is
> verified
> > that the files stage properly after removing the legacy staging
> > C: with a sed script or so remove all do_stage functions and hope the
> best
> > for it.
> > D: remove the recipes that still use legacy staging as apparently no-one
> is
> > enough interested in them to update them.
> >
> > Let us now look at the pro's and con's of these possiblities:
> >
> > From the various calls to fix this that I have seen on the mailing list A
> is
> > not really too desired.
> >
> > B would be nice, but is a hell lot of work. With 1100 recipes, 150 inc
> files
> > and 5 minutes per recipe, this takes about 100 hours.
> > Even with one minute per recipe it would be about 20 hours.
> > Given that lots of the recipes for which this applies seem to be rarely
> used
> > or are older versions of recipes that are not used any more, this seems
> > somewhat a waste of time.
> > Unless someone stands up as volunteer or someone develops an automated
> > solution, I feel this is not going to happen.
> > (and no: I feel no desire at all to spend hours and hours of my spare
> time
> > to convert recipes most of which I am very unlikely to use).
> >
> > C is a quick hack without warranty that the recipe is not broken.
> > I've no idea how you feel about this, but in my opinion I'd rather have a
> > legacy staging recipe which works than a non-legacy staging one which
> might
> > or might not be broken.
> >
> > That leaves option D. Of course removing all recipes that still use
> legacy
> > staging is not desired, as that would also mean e.g. removal of the 53
> > recipes identified by Koen. [1]
> > However, the idea has some merits. Lots of the recipes with legacy
> staging
> > seem to be old recipes. See e.g. the alsa-lib example [3]. By removing
> these
> > at least the time and work needed for B would be less.
> >
> > Now how to proceed?
> > Well that is the reason for this email.
> > I would like to hear your opinions on this, so feel free to voice them.
> > If there is consensus we can start deploying things. If not we might ask
> the
> > TSC for some guidance.
> >
> > To start off the discussion let me give you my personal view.
> >
> > I would be in favour to remove all recipes that use legacy staging and
> that
> > do not fit into one of the following categories:
> > - it is  the most recent version of the package that is build by the
> recipe
> > - it is not the most recent version but all more recent versions have
> > DEFAULT_PREFERENCE = "-1"
> > - it is pinned by a distro
> > - it is a toolchain recipe (gcc, binutils, automake, autoconf and
> probably
> > glibc)
> > - it is a kernel or u-boot recipe
> > The rationale behind this is that it removes a lot of recipes (and hence
> a
> > lot of work converting).
> > Note that the recipes are not gone. They will remain in the stable 2009
> > branch and they can always be retrieved from git.
> > So should someone for whatever reason need a recipe he/she can recover
> it,
> > fix it and put it back.
> >
> > After that we can make an inventory of the work remaining.
> > If there are relatively few recipes remaining it will become a lot
> simpler
> > to find volunteers to clean up those.
> > If there are many e.g. because an orphaned distro or machine pins lots of
> > legacy recipes) we might consider a different scenario.
> >
> > This is my personal view, but ofc I would like to have a discussion on
> this
> > and hear other opinions so preferably we can come to a consensus.
> > The only request I have is that if you advocate a certain solution that
> you
> > are willing to participate in realising that solution.
> > E.g. it is easy to say that B is the desired scenario and that others
> should
> > implement this.
> >
> > Best regards, Frans.
> >
> > PS: if the consensus is to start off removing the legacy recipes as I
> > proposed above, I am more than willing to participate in that.
> > and if someone has a good idea on how to automate identification of
> > qualifying recipes (especially weeding out from the list, the ones we
> still
> > want to retain), I'd love to learn about that too.
> >
> > [1]
> >
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-July/021870.html
> > [2]
> >
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-July/021901.html
> > [3]
> >
> http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg08150.html
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFMSsSJMkyGM64RGpERAhhNAKC6BmsL13nbL3N4z2iirmtkk6JP6ACguLTo
> S6chuyETQHFcfIaiYONuVGY=
> =8fwc
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC] get rid of legacy staging

[Martyn Welch]

Can anyone point me to any documentation that describes what legacy 
staging is and roughly what needs to be done to remove it?

I've looked on the wiki and find nothing, at the moment "legacy staging" 
might as well be a marketing buzz word. I'm sure I'm not alone. I'm sure 
there are loads of recipes that have been converted and I'm sure I 
*could* spend a few hours trying to work out which changes modified them 
to remove "legacy staging", however I wouldn't have any free time to 
convert any of the un-touched recipes...

Martyn

Frans Meulenbroeks wrote:
> Dear all,
>
> The topic of legacy staging has been on the table for probably 8 months or
> so.
> Still we have a lot of recipes that use legacy staging.
> This email tries to stir up the discussion on how to get rid of these.
>
> Most of the major recipes seem to be converted.
> Koen reported 53 recipes with legacy staging after building
> angstrom-gnome-image and openjdk. [1]
> This seems an indication that lots of common and actively used recipes are
> converted.
> However there are still 1100+ recipes and about 150 .inc files that have a
> do_stage rule [2]
>
> This indicates that quite some work is still needed.
> Let's have a look at the options. What I see as possibilities are:
>
> A: accept that we will have lots of recipes around that use legacy staging
> B: update and test all recipes (at least up to the level that it is verified
> that the files stage properly after removing the legacy staging
> C: with a sed script or so remove all do_stage functions and hope the best
> for it.
> D: remove the recipes that still use legacy staging as apparently no-one is
> enough interested in them to update them.
>
> Let us now look at the pro's and con's of these possiblities:
>
> From the various calls to fix this that I have seen on the mailing list A is
> not really too desired.
>
> B would be nice, but is a hell lot of work. With 1100 recipes, 150 inc files
> and 5 minutes per recipe, this takes about 100 hours.
> Even with one minute per recipe it would be about 20 hours.
> Given that lots of the recipes for which this applies seem to be rarely used
> or are older versions of recipes that are not used any more, this seems
> somewhat a waste of time.
> Unless someone stands up as volunteer or someone develops an automated
> solution, I feel this is not going to happen.
> (and no: I feel no desire at all to spend hours and hours of my spare time
> to convert recipes most of which I am very unlikely to use).
>
> C is a quick hack without warranty that the recipe is not broken.
> I've no idea how you feel about this, but in my opinion I'd rather have a
> legacy staging recipe which works than a non-legacy staging one which might
> or might not be broken.
>
> That leaves option D. Of course removing all recipes that still use legacy
> staging is not desired, as that would also mean e.g. removal of the 53
> recipes identified by Koen. [1]
> However, the idea has some merits. Lots of the recipes with legacy staging
> seem to be old recipes. See e.g. the alsa-lib example [3]. By removing these
> at least the time and work needed for B would be less.
>
> Now how to proceed?
> Well that is the reason for this email.
> I would like to hear your opinions on this, so feel free to voice them.
> If there is consensus we can start deploying things. If not we might ask the
> TSC for some guidance.
>
> To start off the discussion let me give you my personal view.
>
> I would be in favour to remove all recipes that use legacy staging and that
> do not fit into one of the following categories:
> - it is  the most recent version of the package that is build by the recipe
> - it is not the most recent version but all more recent versions have
> DEFAULT_PREFERENCE = "-1"
> - it is pinned by a distro
> - it is a toolchain recipe (gcc, binutils, automake, autoconf and probably
> glibc)
> - it is a kernel or u-boot recipe
> The rationale behind this is that it removes a lot of recipes (and hence a
> lot of work converting).
> Note that the recipes are not gone. They will remain in the stable 2009
> branch and they can always be retrieved from git.
> So should someone for whatever reason need a recipe he/she can recover it,
> fix it and put it back.
>
> After that we can make an inventory of the work remaining.
> If there are relatively few recipes remaining it will become a lot simpler
> to find volunteers to clean up those.
> If there are many e.g. because an orphaned distro or machine pins lots of
> legacy recipes) we might consider a different scenario.
>
> This is my personal view, but ofc I would like to have a discussion on this
> and hear other opinions so preferably we can come to a consensus.
> The only request I have is that if you advocate a certain solution that you
> are willing to participate in realising that solution.
> E.g. it is easy to say that B is the desired scenario and that others should
> implement this.
>
> Best regards, Frans.
>
> PS: if the consensus is to start off removing the legacy recipes as I
> proposed above, I am more than willing to participate in that.
> and if someone has a good idea on how to automate identification of
> qualifying recipes (especially weeding out from the list, the ones we still
> want to retain), I'd love to learn about that too.
>
> [1]
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-July/021870.html
> [2]
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-July/021901.html
> [3]
> http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg08150.html
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>   

Re: [RFC] get rid of legacy staging

[Frans Meulenbroeks]

2010/7/24 Martyn Welch <martyn@welchs.me.uk>

> Can anyone point me to any documentation that describes what legacy staging
> is and roughly what needs to be done to remove it?
>
> I've looked on the wiki and find nothing, at the moment "legacy staging"
> might as well be a marketing buzz word. I'm sure I'm not alone. I'm sure
> there are loads of recipes that have been converted and I'm sure I *could*
> spend a few hours trying to work out which changes modified them to remove
> "legacy staging", however I wouldn't have any free time to convert any of
> the un-touched recipes...
>
> Martyn
>

There was a post half a year or so ago from Koen, but I can't find it.
Basically it boils down to removing do_stage from a recipe in which case
do_install is used to install things in staging
in some cases do_install need to be modified to deal with peculiarities that
were done in do_stage

For native recipes NATIVE_INSTALL_WORKS = "1" may need to be added.

If you are interested in tackling some recipes, perhaps also ask for advice
in #oe on freenode irc

Frans.

>
> Frans Meulenbroeks wrote:
>
>> Dear all,
>>
>> The topic of legacy staging has been on the table for probably 8 months or
>> so.
>> Still we have a lot of recipes that use legacy staging.
>> This email tries to stir up the discussion on how to get rid of these.
>>
>> Most of the major recipes seem to be converted.
>> Koen reported 53 recipes with legacy staging after building
>> angstrom-gnome-image and openjdk. [1]
>> This seems an indication that lots of common and actively used recipes are
>> converted.
>> However there are still 1100+ recipes and about 150 .inc files that have a
>> do_stage rule [2]
>>
>> This indicates that quite some work is still needed.
>> Let's have a look at the options. What I see as possibilities are:
>>
>> A: accept that we will have lots of recipes around that use legacy staging
>> B: update and test all recipes (at least up to the level that it is
>> verified
>> that the files stage properly after removing the legacy staging
>> C: with a sed script or so remove all do_stage functions and hope the best
>> for it.
>> D: remove the recipes that still use legacy staging as apparently no-one
>> is
>> enough interested in them to update them.
>>
>> Let us now look at the pro's and con's of these possiblities:
>>
>> From the various calls to fix this that I have seen on the mailing list A
>> is
>> not really too desired.
>>
>> B would be nice, but is a hell lot of work. With 1100 recipes, 150 inc
>> files
>> and 5 minutes per recipe, this takes about 100 hours.
>> Even with one minute per recipe it would be about 20 hours.
>> Given that lots of the recipes for which this applies seem to be rarely
>> used
>> or are older versions of recipes that are not used any more, this seems
>> somewhat a waste of time.
>> Unless someone stands up as volunteer or someone develops an automated
>> solution, I feel this is not going to happen.
>> (and no: I feel no desire at all to spend hours and hours of my spare time
>> to convert recipes most of which I am very unlikely to use).
>>
>> C is a quick hack without warranty that the recipe is not broken.
>> I've no idea how you feel about this, but in my opinion I'd rather have a
>> legacy staging recipe which works than a non-legacy staging one which
>> might
>> or might not be broken.
>>
>> That leaves option D. Of course removing all recipes that still use legacy
>> staging is not desired, as that would also mean e.g. removal of the 53
>> recipes identified by Koen. [1]
>> However, the idea has some merits. Lots of the recipes with legacy staging
>> seem to be old recipes. See e.g. the alsa-lib example [3]. By removing
>> these
>> at least the time and work needed for B would be less.
>>
>> Now how to proceed?
>> Well that is the reason for this email.
>> I would like to hear your opinions on this, so feel free to voice them.
>> If there is consensus we can start deploying things. If not we might ask
>> the
>> TSC for some guidance.
>>
>> To start off the discussion let me give you my personal view.
>>
>> I would be in favour to remove all recipes that use legacy staging and
>> that
>> do not fit into one of the following categories:
>> - it is  the most recent version of the package that is build by the
>> recipe
>> - it is not the most recent version but all more recent versions have
>> DEFAULT_PREFERENCE = "-1"
>> - it is pinned by a distro
>> - it is a toolchain recipe (gcc, binutils, automake, autoconf and probably
>> glibc)
>> - it is a kernel or u-boot recipe
>> The rationale behind this is that it removes a lot of recipes (and hence a
>> lot of work converting).
>> Note that the recipes are not gone. They will remain in the stable 2009
>> branch and they can always be retrieved from git.
>> So should someone for whatever reason need a recipe he/she can recover it,
>> fix it and put it back.
>>
>> After that we can make an inventory of the work remaining.
>> If there are relatively few recipes remaining it will become a lot simpler
>> to find volunteers to clean up those.
>> If there are many e.g. because an orphaned distro or machine pins lots of
>> legacy recipes) we might consider a different scenario.
>>
>> This is my personal view, but ofc I would like to have a discussion on
>> this
>> and hear other opinions so preferably we can come to a consensus.
>> The only request I have is that if you advocate a certain solution that
>> you
>> are willing to participate in realising that solution.
>> E.g. it is easy to say that B is the desired scenario and that others
>> should
>> implement this.
>>
>> Best regards, Frans.
>>
>> PS: if the consensus is to start off removing the legacy recipes as I
>> proposed above, I am more than willing to participate in that.
>> and if someone has a good idea on how to automate identification of
>> qualifying recipes (especially weeding out from the list, the ones we
>> still
>> want to retain), I'd love to learn about that too.
>>
>> [1]
>>
>> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-July/021870.html
>> [2]
>>
>> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-July/021901.html
>> [3]
>>
>> http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg08150.html
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC] get rid of legacy staging

[Detlef Vollmann]

On 07/24/10 16:35, Frans Meulenbroeks wrote:
> 2010/7/24 Martyn Welch <martyn@welchs.me.uk>
> 
>> Can anyone point me to any documentation that describes what legacy staging
>> is and roughly what needs to be done to remove it?

> 
> There was a post half a year or so ago from Koen, but I can't find it.
> Basically it boils down to removing do_stage from a recipe in which case
> do_install is used to install things in staging
> in some cases do_install need to be modified to deal with peculiarities that
> were done in do_stage
> 
> For native recipes NATIVE_INSTALL_WORKS = "1" may need to be added.
That's not really much of an explanation.
Let's take an example.  I have two out of tree kernel modules A and B.
B depends on A.
With "legacy" staging, in A_1.0.bb I have a do_install, that copies
the kernel object, and a do_stage, that copies the header file at
a place where B_1.0.bb can find it.

How do I do that with non-"legacy" staging?

   Detlef

Re: [RFC] get rid of legacy staging

[Koen Kooi]

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

On 24-07-10 17:05, Detlef Vollmann wrote:
> On 07/24/10 16:35, Frans Meulenbroeks wrote:
>> 2010/7/24 Martyn Welch <martyn@welchs.me.uk>
>>
>>> Can anyone point me to any documentation that describes what legacy
>>> staging
>>> is and roughly what needs to be done to remove it?
> 
>>
>> There was a post half a year or so ago from Koen, but I can't find it.
>> Basically it boils down to removing do_stage from a recipe in which case
>> do_install is used to install things in staging
>> in some cases do_install need to be modified to deal with
>> peculiarities that
>> were done in do_stage
>>
>> For native recipes NATIVE_INSTALL_WORKS = "1" may need to be added.
> That's not really much of an explanation.
> Let's take an example.  I have two out of tree kernel modules A and B.
> B depends on A.
> With "legacy" staging, in A_1.0.bb I have a do_install, that copies
> the kernel object, and a do_stage, that copies the header file at
> a place where B_1.0.bb can find it.
> 
> How do I do that with non-"legacy" staging?

You copy the header in do_install to ${D}${includedir} or a subdir of
that depending on the header.

Cheat sheet:

STAGING_BINDIR -> ${D}${bindir}
STAGING_INCDIR -> ${D}${includedir}
STAGING_LIBDIR -> ${D}${libdir}
STAGING_DATADIR -> ${D}${datadir}

And if your recipe uses BBCLASS_EXTEND = native *and* 'make install'
doesn't do the job (e.g. using do_install_append), use
NATIVE_INSTALL_WORKS = "1"

If you use packaged-staging it's easy to do dpkg-deb -c on the staging
packages before and after the changes.

regards,

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

iD8DBQFMSwP0MkyGM64RGpERAlrAAJ0Rn/6RY3f/wSuN++NEFJjRW4y6nwCgn+js
2prw5jIj56+M4syM4ZOIHtU=
=tisQ
-----END PGP SIGNATURE-----

Re: [RFC] get rid of legacy staging

[Detlef Vollmann]

Thanks!
   Detlef

On 07/24/10 17:17, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 24-07-10 17:05, Detlef Vollmann wrote:
>> On 07/24/10 16:35, Frans Meulenbroeks wrote:
>>> 2010/7/24 Martyn Welch <martyn@welchs.me.uk>
>>>
>>>> Can anyone point me to any documentation that describes what legacy
>>>> staging
>>>> is and roughly what needs to be done to remove it?
>>> There was a post half a year or so ago from Koen, but I can't find it.
>>> Basically it boils down to removing do_stage from a recipe in which case
>>> do_install is used to install things in staging
>>> in some cases do_install need to be modified to deal with
>>> peculiarities that
>>> were done in do_stage
>>>
>>> For native recipes NATIVE_INSTALL_WORKS = "1" may need to be added.
>> That's not really much of an explanation.
>> Let's take an example.  I have two out of tree kernel modules A and B.
>> B depends on A.
>> With "legacy" staging, in A_1.0.bb I have a do_install, that copies
>> the kernel object, and a do_stage, that copies the header file at
>> a place where B_1.0.bb can find it.
>>
>> How do I do that with non-"legacy" staging?
> 
> You copy the header in do_install to ${D}${includedir} or a subdir of
> that depending on the header.
> 
> Cheat sheet:
> 
> STAGING_BINDIR -> ${D}${bindir}
> STAGING_INCDIR -> ${D}${includedir}
> STAGING_LIBDIR -> ${D}${libdir}
> STAGING_DATADIR -> ${D}${datadir}
> 
> And if your recipe uses BBCLASS_EXTEND = native *and* 'make install'
> doesn't do the job (e.g. using do_install_append), use
> NATIVE_INSTALL_WORKS = "1"
> 
> If you use packaged-staging it's easy to do dpkg-deb -c on the staging
> packages before and after the changes.
> 
> regards,
> 
> Koen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
> 
> iD8DBQFMSwP0MkyGM64RGpERAlrAAJ0Rn/6RY3f/wSuN++NEFJjRW4y6nwCgn+js
> 2prw5jIj56+M4syM4ZOIHtU=
> =tisQ
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

Re: [RFC] get rid of legacy staging

[Frans Meulenbroeks]

2010/7/24 Detlef Vollmann <dv@vollmann.ch>

> On 07/24/10 16:35, Frans Meulenbroeks wrote:
>
>> 2010/7/24 Martyn Welch <martyn@welchs.me.uk>
>>
>>  Can anyone point me to any documentation that describes what legacy
>>> staging
>>> is and roughly what needs to be done to remove it?
>>>
>>
>
>> There was a post half a year or so ago from Koen, but I can't find it.
>> Basically it boils down to removing do_stage from a recipe in which case
>> do_install is used to install things in staging
>> in some cases do_install need to be modified to deal with peculiarities
>> that
>> were done in do_stage
>>
>> For native recipes NATIVE_INSTALL_WORKS = "1" may need to be added.
>>
> That's not really much of an explanation.
> Let's take an example.  I have two out of tree kernel modules A and B.
> B depends on A.
> With "legacy" staging, in A_1.0.bb I have a do_install, that copies
> the kernel object, and a do_stage, that copies the header file at
> a place where B_1.0.bb can find it.
>
> How do I do that with non-"legacy" staging?
>

Apologies if my explanation was too brief. Didn't have too much time (and
still haven't)
I hope Koen's explanation below helps.
The way I perceive it is that the non-legacy staging is performed by doing a
do_install with the staging dir as target directory.
Guess someone will correct this if I am wrong.

Frans

>
>  Detlef
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC] get rid of legacy staging

[Chris Larson]

On Sat, Jul 24, 2010 at 9:08 AM, Frans Meulenbroeks <
fransmeulenbroeks@gmail.com> wrote:

> 2010/7/24 Detlef Vollmann <dv@vollmann.ch>
>
> > On 07/24/10 16:35, Frans Meulenbroeks wrote:
> >
> >> 2010/7/24 Martyn Welch <martyn@welchs.me.uk>
> >>
> >>  Can anyone point me to any documentation that describes what legacy
> >>> staging
> >>> is and roughly what needs to be done to remove it?
> >>>
> >>
> >
> >> There was a post half a year or so ago from Koen, but I can't find it.
> >> Basically it boils down to removing do_stage from a recipe in which case
> >> do_install is used to install things in staging
> >> in some cases do_install need to be modified to deal with peculiarities
> >> that
> >> were done in do_stage
> >>
> >> For native recipes NATIVE_INSTALL_WORKS = "1" may need to be added.
> >>
> > That's not really much of an explanation.
> > Let's take an example.  I have two out of tree kernel modules A and B.
> > B depends on A.
> > With "legacy" staging, in A_1.0.bb I have a do_install, that copies
> > the kernel object, and a do_stage, that copies the header file at
> > a place where B_1.0.bb can find it.
> >
> > How do I do that with non-"legacy" staging?
> >
>
> Apologies if my explanation was too brief. Didn't have too much time (and
> still haven't)
> I hope Koen's explanation below helps.
> The way I perceive it is that the non-legacy staging is performed by doing
> a
> do_install with the staging dir as target directory.
> Guess someone will correct this if I am wrong.


You never touch a staging directory from do_install, ever.  You install into
the usual paths, relative to ${D}, and the machinery in the classes will
automatically populate staging from that.  If you need to mangle a file
differently in staging from how you want it in your package, you can install
a hook that will be called at staging population time.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: [RFC] get rid of legacy staging

[Frans Meulenbroeks]

2010/7/24 Chris Larson <clarson@kergoth.com>

> On Sat, Jul 24, 2010 at 9:08 AM, Frans Meulenbroeks <
> fransmeulenbroeks@gmail.com> wrote:
>
> > 2010/7/24 Detlef Vollmann <dv@vollmann.ch>
> >
> > > On 07/24/10 16:35, Frans Meulenbroeks wrote:
> > >
> > >> 2010/7/24 Martyn Welch <martyn@welchs.me.uk>
> > >>
> > >>  Can anyone point me to any documentation that describes what legacy
> > >>> staging
> > >>> is and roughly what needs to be done to remove it?
> > >>>
> > >>
> > >
> > >> There was a post half a year or so ago from Koen, but I can't find it.
> > >> Basically it boils down to removing do_stage from a recipe in which
> case
> > >> do_install is used to install things in staging
> > >> in some cases do_install need to be modified to deal with
> peculiarities
> > >> that
> > >> were done in do_stage
> > >>
> > >> For native recipes NATIVE_INSTALL_WORKS = "1" may need to be added.
> > >>
> > > That's not really much of an explanation.
> > > Let's take an example.  I have two out of tree kernel modules A and B.
> > > B depends on A.
> > > With "legacy" staging, in A_1.0.bb I have a do_install, that copies
> > > the kernel object, and a do_stage, that copies the header file at
> > > a place where B_1.0.bb can find it.
> > >
> > > How do I do that with non-"legacy" staging?
> > >
> >
> > Apologies if my explanation was too brief. Didn't have too much time (and
> > still haven't)
> > I hope Koen's explanation below helps.
> > The way I perceive it is that the non-legacy staging is performed by
> doing
> > a
> > do_install with the staging dir as target directory.
> > Guess someone will correct this if I am wrong.
>
>
> You never touch a staging directory from do_install, ever.  You install
> into
> the usual paths, relative to ${D}, and the machinery in the classes will
> automatically populate staging from that.  If you need to mangle a file
>

That is what actually what I wanted to say but apparently failed to express
properly
It is indeed the machinery that does the work, not the user itself.

Frans.

> differently in staging from how you want it in your package, you can
> install
> a hook that will be called at staging population time.
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC] get rid of legacy staging

[Khem Raj]

On Sat, Jul 24, 2010 at 10:22 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2010/7/24 Chris Larson <clarson@kergoth.com>
>
>> On Sat, Jul 24, 2010 at 9:08 AM, Frans Meulenbroeks <
>> fransmeulenbroeks@gmail.com> wrote:
>>
>> > 2010/7/24 Detlef Vollmann <dv@vollmann.ch>
>> >
>> > > On 07/24/10 16:35, Frans Meulenbroeks wrote:
>> > >
>> > >> 2010/7/24 Martyn Welch <martyn@welchs.me.uk>
>> > >>
>> > >>  Can anyone point me to any documentation that describes what legacy
>> > >>> staging
>> > >>> is and roughly what needs to be done to remove it?
>> > >>>
>> > >>
>> > >
>> > >> There was a post half a year or so ago from Koen, but I can't find it.
>> > >> Basically it boils down to removing do_stage from a recipe in which
>> case
>> > >> do_install is used to install things in staging
>> > >> in some cases do_install need to be modified to deal with
>> peculiarities
>> > >> that
>> > >> were done in do_stage
>> > >>
>> > >> For native recipes NATIVE_INSTALL_WORKS = "1" may need to be added.
>> > >>
>> > > That's not really much of an explanation.
>> > > Let's take an example.  I have two out of tree kernel modules A and B.
>> > > B depends on A.
>> > > With "legacy" staging, in A_1.0.bb I have a do_install, that copies
>> > > the kernel object, and a do_stage, that copies the header file at
>> > > a place where B_1.0.bb can find it.
>> > >
>> > > How do I do that with non-"legacy" staging?
>> > >
>> >
>> > Apologies if my explanation was too brief. Didn't have too much time (and
>> > still haven't)
>> > I hope Koen's explanation below helps.
>> > The way I perceive it is that the non-legacy staging is performed by
>> doing
>> > a
>> > do_install with the staging dir as target directory.
>> > Guess someone will correct this if I am wrong.
>>
>>
>> You never touch a staging directory from do_install, ever.  You install
>> into
>> the usual paths, relative to ${D}, and the machinery in the classes will
>> automatically populate staging from that.  If you need to mangle a file
>>
>
> That is what actually what I wanted to say but apparently failed to express
> properly
> It is indeed the machinery that does the work, not the user itself.
>
> Frans.
>
>> differently in staging from how you want it in your package, you can
>> install
>> a hook that will be called at staging population time.
>> --


when we are at it may be at the same time look into converting native recipes
to use BBCLASSEXTEND. In my experience whenever I went to remove legacy
staging I ended up converting the native recipes to use BBCLASSEXTEND along
with

I have a huge patch where I have removed inherit autotools_staging from
all recipes in OE. I havent tested it so far but should be done in few days

-Khem

Re: [RFC] get rid of legacy staging

[Frans Meulenbroeks]

2010/7/24 Khem Raj <raj.khem@gmail.com>

> On Sat, Jul 24, 2010 at 10:22 AM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
> > 2010/7/24 Chris Larson <clarson@kergoth.com>
> >
> >> On Sat, Jul 24, 2010 at 9:08 AM, Frans Meulenbroeks <
> >> fransmeulenbroeks@gmail.com> wrote:
> >>
> >> > 2010/7/24 Detlef Vollmann <dv@vollmann.ch>
> >> >
> >> > > On 07/24/10 16:35, Frans Meulenbroeks wrote:
> >> > >
> >> > >> 2010/7/24 Martyn Welch <martyn@welchs.me.uk>
> >> > >>
> >> > >>  Can anyone point me to any documentation that describes what
> legacy
> >> > >>> staging
> >> > >>> is and roughly what needs to be done to remove it?
> >> > >>>
> >> > >>
> >> > >
> >> > >> There was a post half a year or so ago from Koen, but I can't find
> it.
> >> > >> Basically it boils down to removing do_stage from a recipe in which
> >> case
> >> > >> do_install is used to install things in staging
> >> > >> in some cases do_install need to be modified to deal with
> >> peculiarities
> >> > >> that
> >> > >> were done in do_stage
> >> > >>
> >> > >> For native recipes NATIVE_INSTALL_WORKS = "1" may need to be added.
> >> > >>
> >> > > That's not really much of an explanation.
> >> > > Let's take an example.  I have two out of tree kernel modules A and
> B.
> >> > > B depends on A.
> >> > > With "legacy" staging, in A_1.0.bb I have a do_install, that copies
> >> > > the kernel object, and a do_stage, that copies the header file at
> >> > > a place where B_1.0.bb can find it.
> >> > >
> >> > > How do I do that with non-"legacy" staging?
> >> > >
> >> >
> >> > Apologies if my explanation was too brief. Didn't have too much time
> (and
> >> > still haven't)
> >> > I hope Koen's explanation below helps.
> >> > The way I perceive it is that the non-legacy staging is performed by
> >> doing
> >> > a
> >> > do_install with the staging dir as target directory.
> >> > Guess someone will correct this if I am wrong.
> >>
> >>
> >> You never touch a staging directory from do_install, ever.  You install
> >> into
> >> the usual paths, relative to ${D}, and the machinery in the classes will
> >> automatically populate staging from that.  If you need to mangle a file
> >>
> >
> > That is what actually what I wanted to say but apparently failed to
> express
> > properly
> > It is indeed the machinery that does the work, not the user itself.
> >
> > Frans.
> >
> >> differently in staging from how you want it in your package, you can
> >> install
> >> a hook that will be called at staging population time.
> >> --
>
>
> when we are at it may be at the same time look into converting native
> recipes
> to use BBCLASSEXTEND. In my experience whenever I went to remove legacy
> staging I ended up converting the native recipes to use BBCLASSEXTEND along
> with
>

We still have 400 native recipes. in 270 or so directories

>
> I have a huge patch where I have removed inherit autotools_staging from
> all recipes in OE. I havent tested it so far but should be done in few days
>

Cool, that would be a great step.

>
> -Khem
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC] get rid of legacy staging

[Tom Rini]

Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 24-07-10 17:05, Detlef Vollmann wrote:
>> On 07/24/10 16:35, Frans Meulenbroeks wrote:
>>> 2010/7/24 Martyn Welch <martyn@welchs.me.uk>
>>>
>>>> Can anyone point me to any documentation that describes what legacy
>>>> staging
>>>> is and roughly what needs to be done to remove it?
>>> There was a post half a year or so ago from Koen, but I can't find it.
>>> Basically it boils down to removing do_stage from a recipe in which case
>>> do_install is used to install things in staging
>>> in some cases do_install need to be modified to deal with
>>> peculiarities that
>>> were done in do_stage
>>>
>>> For native recipes NATIVE_INSTALL_WORKS = "1" may need to be added.
>> That's not really much of an explanation.
>> Let's take an example.  I have two out of tree kernel modules A and B.
>> B depends on A.
>> With "legacy" staging, in A_1.0.bb I have a do_install, that copies
>> the kernel object, and a do_stage, that copies the header file at
>> a place where B_1.0.bb can find it.
>>
>> How do I do that with non-"legacy" staging?
> 
> You copy the header in do_install to ${D}${includedir} or a subdir of
> that depending on the header.
> 
> Cheat sheet:
> 
> STAGING_BINDIR -> ${D}${bindir}
> STAGING_INCDIR -> ${D}${includedir}
> STAGING_LIBDIR -> ${D}${libdir}
> STAGING_DATADIR -> ${D}${datadir}
> 
> And if your recipe uses BBCLASS_EXTEND = native *and* 'make install'
> doesn't do the job (e.g. using do_install_append), use
> NATIVE_INSTALL_WORKS = "1"
> 
> If you use packaged-staging it's easy to do dpkg-deb -c on the staging
> packages before and after the changes.

http://wiki.openembedded.org/index.php/Legacy_staging
and is linked from 
http://wiki.openembedded.org/index.php/OpenEmbeddedJanitors

-- 
Tom Rini
Mentor Graphics Corporation

Re: [RFC] get rid of legacy staging

[C Michael Sundius]

every time I see a conversation on this list that says something to the
effect of "we have xxx number of recipes that do this" or "if we make this
sort of change we'll have to change yyy number of recipes" I cringe. I ran:

[msundius@msundius-lnx1 recipes]$ find . -type f | grep "\.bb$" | wc
   8581    8581  276766
[msundius@msundius-lnx1 recipes]$ ls -1 | wc
   2023    2023   18851

8500 recipes just doesn't seem like a scalable number of recipes to manage
w/ our development community. Its problematic for the following reasons:

1) making a change that affects compatibility is difficult if not impossible
2) most people working w/ embedded distros want only a small percentage of
this beast
3) building involves bitbake parsing all of these recipes before going to do
the tree of what actually needs to be built.
there are probably more complaints from the masses

It seems to me that we need to decouple in a formal way the recipes from OE
(classes and config files) and from each other.
I am proposing that we do the following:
- that we define exactly what it means to conform to a particular version of
the OE Recipe API (or whatever you call it).
- that we "fetch" recipes from well known repositories/mirrors (or locally)
in the same way we fetch tarballs.
- we parse recipes as we build the dependency tree.

That way we don't have to look through the entire list 8500 recipes (parsing
them all) before we build our tiny little embedded application that controls
a refrigerator's ice making machine or whatever you make.

For us, we simply don't use most of all of the recipes and I have found it
hard to manage the disparity of the entire official tree vs the recipes that
we use. I have simply created my own (sub)tree that is a subset to the
greater tree.

I also like the idea that we would be able to append our own configuration
data patches etc for selected standard recipes (that could be "fetched" from
somewhere) so that we would not really have to merge all of those specifics
of our own system into the repository of recipes used by the whole world
(i.e. noone cares about the busybox config file we use or a patch to the
kernel to fix a dumb thing our HW engineers did). somthing akin to the
.bbappend discussion as of late

I realize that this is off topic here. I also am not qualified to propose
how to implement such a solution. I'm just wondering if that might have
already occurred to any of us that there's a fundamental issue that detracts
us from creating a truly independent build framework. I'm also not trying to
be a complainer.. I've been thinking about this for a long time and I'd like
to help... I'm just not that good  w/ python :]

Back to the discussion at hand, If we have a (versioned) compatibility
standard for recipes then we could simply bump the number and exclude old
recipes until their maintainer or someone who needed it, got around to
upgrading the recipe.

Mike

On Sat, Jul 24, 2010 at 2:57 AM, Frans Meulenbroeks <
fransmeulenbroeks@gmail.com> wrote:

> Dear all,
>
> The topic of legacy staging has been on the table for probably 8 months or
> so.
> Still we have a lot of recipes that use legacy staging.
> This email tries to stir up the discussion on how to get rid of these.
>
> Most of the major recipes seem to be converted.
> Koen reported 53 recipes with legacy staging after building
> angstrom-gnome-image and openjdk. [1]
> This seems an indication that lots of common and actively used recipes are
> converted.
> However there are still 1100+ recipes and about 150 .inc files that have a
> do_stage rule [2]
>
> This indicates that quite some work is still needed.
> Let's have a look at the options. What I see as possibilities are:
>
> A: accept that we will have lots of recipes around that use legacy staging
> B: update and test all recipes (at least up to the level that it is
> verified
> that the files stage properly after removing the legacy staging
> C: with a sed script or so remove all do_stage functions and hope the best
> for it.
> D: remove the recipes that still use legacy staging as apparently no-one is
> enough interested in them to update them.
>
> Let us now look at the pro's and con's of these possiblities:
>
> From the various calls to fix this that I have seen on the mailing list A
> is
> not really too desired.
>
> B would be nice, but is a hell lot of work. With 1100 recipes, 150 inc
> files
> and 5 minutes per recipe, this takes about 100 hours.
> Even with one minute per recipe it would be about 20 hours.
> Given that lots of the recipes for which this applies seem to be rarely
> used
> or are older versions of recipes that are not used any more, this seems
> somewhat a waste of time.
> Unless someone stands up as volunteer or someone develops an automated
> solution, I feel this is not going to happen.
> (and no: I feel no desire at all to spend hours and hours of my spare time
> to convert recipes most of which I am very unlikely to use).
>
> C is a quick hack without warranty that the recipe is not broken.
> I've no idea how you feel about this, but in my opinion I'd rather have a
> legacy staging recipe which works than a non-legacy staging one which might
> or might not be broken.
>
> That leaves option D. Of course removing all recipes that still use legacy
> staging is not desired, as that would also mean e.g. removal of the 53
> recipes identified by Koen. [1]
> However, the idea has some merits. Lots of the recipes with legacy staging
> seem to be old recipes. See e.g. the alsa-lib example [3]. By removing
> these
> at least the time and work needed for B would be less.
>
> Now how to proceed?
> Well that is the reason for this email.
> I would like to hear your opinions on this, so feel free to voice them.
> If there is consensus we can start deploying things. If not we might ask
> the
> TSC for some guidance.
>
> To start off the discussion let me give you my personal view.
>
> I would be in favour to remove all recipes that use legacy staging and that
> do not fit into one of the following categories:
> - it is  the most recent version of the package that is build by the recipe
> - it is not the most recent version but all more recent versions have
> DEFAULT_PREFERENCE = "-1"
> - it is pinned by a distro
> - it is a toolchain recipe (gcc, binutils, automake, autoconf and probably
> glibc)
> - it is a kernel or u-boot recipe
> The rationale behind this is that it removes a lot of recipes (and hence a
> lot of work converting).
> Note that the recipes are not gone. They will remain in the stable 2009
> branch and they can always be retrieved from git.
> So should someone for whatever reason need a recipe he/she can recover it,
> fix it and put it back.
>
> After that we can make an inventory of the work remaining.
> If there are relatively few recipes remaining it will become a lot simpler
> to find volunteers to clean up those.
> If there are many e.g. because an orphaned distro or machine pins lots of
> legacy recipes) we might consider a different scenario.
>
> This is my personal view, but ofc I would like to have a discussion on this
> and hear other opinions so preferably we can come to a consensus.
> The only request I have is that if you advocate a certain solution that you
> are willing to participate in realising that solution.
> E.g. it is easy to say that B is the desired scenario and that others
> should
> implement this.
>
> Best regards, Frans.
>
> PS: if the consensus is to start off removing the legacy recipes as I
> proposed above, I am more than willing to participate in that.
> and if someone has a good idea on how to automate identification of
> qualifying recipes (especially weeding out from the list, the ones we still
> want to retain), I'd love to learn about that too.
>
> [1]
>
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-July/021870.html
> [2]
>
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-July/021901.html
> [3]
>
> http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg08150.html
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC] get rid of legacy staging

[Chris Larson]

The way bitbake works today, it can't build *anything* unless it's parsed
*everything*, because anything could have PROVIDES / RPROVIDES what you're
wanting to build.  If you want to shift things to a server, which I agree
would be nice, you'd have to have a daemon running there to make available
the full dependency information.

On Mon, Jul 26, 2010 at 1:59 PM, C Michael Sundius <msundius@sundius.com>wrote:

> every time I see a conversation on this list that says something to the
> effect of "we have xxx number of recipes that do this" or "if we make this
> sort of change we'll have to change yyy number of recipes" I cringe. I ran:
>
> [msundius@msundius-lnx1 recipes]$ find . -type f | grep "\.bb$" | wc
>   8581    8581  276766
> [msundius@msundius-lnx1 recipes]$ ls -1 | wc
>   2023    2023   18851
>
> 8500 recipes just doesn't seem like a scalable number of recipes to manage
> w/ our development community. Its problematic for the following reasons:
>
> 1) making a change that affects compatibility is difficult if not
> impossible
> 2) most people working w/ embedded distros want only a small percentage of
> this beast
> 3) building involves bitbake parsing all of these recipes before going to
> do
> the tree of what actually needs to be built.
> there are probably more complaints from the masses
>
> It seems to me that we need to decouple in a formal way the recipes from OE
> (classes and config files) and from each other.
> I am proposing that we do the following:
> - that we define exactly what it means to conform to a particular version
> of
> the OE Recipe API (or whatever you call it).
> - that we "fetch" recipes from well known repositories/mirrors (or locally)
> in the same way we fetch tarballs.
> - we parse recipes as we build the dependency tree.
>
> That way we don't have to look through the entire list 8500 recipes
> (parsing
> them all) before we build our tiny little embedded application that
> controls
> a refrigerator's ice making machine or whatever you make.
>
> For us, we simply don't use most of all of the recipes and I have found it
> hard to manage the disparity of the entire official tree vs the recipes
> that
> we use. I have simply created my own (sub)tree that is a subset to the
> greater tree.
>
> I also like the idea that we would be able to append our own configuration
> data patches etc for selected standard recipes (that could be "fetched"
> from
> somewhere) so that we would not really have to merge all of those specifics
> of our own system into the repository of recipes used by the whole world
> (i.e. noone cares about the busybox config file we use or a patch to the
> kernel to fix a dumb thing our HW engineers did). somthing akin to the
> .bbappend discussion as of late
>
> I realize that this is off topic here. I also am not qualified to propose
> how to implement such a solution. I'm just wondering if that might have
> already occurred to any of us that there's a fundamental issue that
> detracts
> us from creating a truly independent build framework. I'm also not trying
> to
> be a complainer.. I've been thinking about this for a long time and I'd
> like
> to help... I'm just not that good  w/ python :]
>
> Back to the discussion at hand, If we have a (versioned) compatibility
> standard for recipes then we could simply bump the number and exclude old
> recipes until their maintainer or someone who needed it, got around to
> upgrading the recipe.
>
> Mike
>
> On Sat, Jul 24, 2010 at 2:57 AM, Frans Meulenbroeks <
> fransmeulenbroeks@gmail.com> wrote:
>
> > Dear all,
> >
> > The topic of legacy staging has been on the table for probably 8 months
> or
> > so.
> > Still we have a lot of recipes that use legacy staging.
> > This email tries to stir up the discussion on how to get rid of these.
> >
> > Most of the major recipes seem to be converted.
> > Koen reported 53 recipes with legacy staging after building
> > angstrom-gnome-image and openjdk. [1]
> > This seems an indication that lots of common and actively used recipes
> are
> > converted.
> > However there are still 1100+ recipes and about 150 .inc files that have
> a
> > do_stage rule [2]
> >
> > This indicates that quite some work is still needed.
> > Let's have a look at the options. What I see as possibilities are:
> >
> > A: accept that we will have lots of recipes around that use legacy
> staging
> > B: update and test all recipes (at least up to the level that it is
> > verified
> > that the files stage properly after removing the legacy staging
> > C: with a sed script or so remove all do_stage functions and hope the
> best
> > for it.
> > D: remove the recipes that still use legacy staging as apparently no-one
> is
> > enough interested in them to update them.
> >
> > Let us now look at the pro's and con's of these possiblities:
> >
> > From the various calls to fix this that I have seen on the mailing list A
> > is
> > not really too desired.
> >
> > B would be nice, but is a hell lot of work. With 1100 recipes, 150 inc
> > files
> > and 5 minutes per recipe, this takes about 100 hours.
> > Even with one minute per recipe it would be about 20 hours.
> > Given that lots of the recipes for which this applies seem to be rarely
> > used
> > or are older versions of recipes that are not used any more, this seems
> > somewhat a waste of time.
> > Unless someone stands up as volunteer or someone develops an automated
> > solution, I feel this is not going to happen.
> > (and no: I feel no desire at all to spend hours and hours of my spare
> time
> > to convert recipes most of which I am very unlikely to use).
> >
> > C is a quick hack without warranty that the recipe is not broken.
> > I've no idea how you feel about this, but in my opinion I'd rather have a
> > legacy staging recipe which works than a non-legacy staging one which
> might
> > or might not be broken.
> >
> > That leaves option D. Of course removing all recipes that still use
> legacy
> > staging is not desired, as that would also mean e.g. removal of the 53
> > recipes identified by Koen. [1]
> > However, the idea has some merits. Lots of the recipes with legacy
> staging
> > seem to be old recipes. See e.g. the alsa-lib example [3]. By removing
> > these
> > at least the time and work needed for B would be less.
> >
> > Now how to proceed?
> > Well that is the reason for this email.
> > I would like to hear your opinions on this, so feel free to voice them.
> > If there is consensus we can start deploying things. If not we might ask
> > the
> > TSC for some guidance.
> >
> > To start off the discussion let me give you my personal view.
> >
> > I would be in favour to remove all recipes that use legacy staging and
> that
> > do not fit into one of the following categories:
> > - it is  the most recent version of the package that is build by the
> recipe
> > - it is not the most recent version but all more recent versions have
> > DEFAULT_PREFERENCE = "-1"
> > - it is pinned by a distro
> > - it is a toolchain recipe (gcc, binutils, automake, autoconf and
> probably
> > glibc)
> > - it is a kernel or u-boot recipe
> > The rationale behind this is that it removes a lot of recipes (and hence
> a
> > lot of work converting).
> > Note that the recipes are not gone. They will remain in the stable 2009
> > branch and they can always be retrieved from git.
> > So should someone for whatever reason need a recipe he/she can recover
> it,
> > fix it and put it back.
> >
> > After that we can make an inventory of the work remaining.
> > If there are relatively few recipes remaining it will become a lot
> simpler
> > to find volunteers to clean up those.
> > If there are many e.g. because an orphaned distro or machine pins lots of
> > legacy recipes) we might consider a different scenario.
> >
> > This is my personal view, but ofc I would like to have a discussion on
> this
> > and hear other opinions so preferably we can come to a consensus.
> > The only request I have is that if you advocate a certain solution that
> you
> > are willing to participate in realising that solution.
> > E.g. it is easy to say that B is the desired scenario and that others
> > should
> > implement this.
> >
> > Best regards, Frans.
> >
> > PS: if the consensus is to start off removing the legacy recipes as I
> > proposed above, I am more than willing to participate in that.
> > and if someone has a good idea on how to automate identification of
> > qualifying recipes (especially weeding out from the list, the ones we
> still
> > want to retain), I'd love to learn about that too.
> >
> > [1]
> >
> >
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-July/021870.html
> > [2]
> >
> >
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-July/021901.html
> > [3]
> >
> >
> http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg08150.html
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: [RFC] get rid of legacy staging

[Frans Meulenbroeks]

2010/7/26 Chris Larson <clarson@kergoth.com>

> The way bitbake works today, it can't build *anything* unless it's parsed
> *everything*, because anything could have PROVIDES / RPROVIDES what you're
> wanting to build.  If you want to shift things to a server, which I agree
> would be nice, you'd have to have a daemon running there to make available
> the full dependency information.
>
> On Mon, Jul 26, 2010 at 1:59 PM, C Michael Sundius <msundius@sundius.com
> >wrote:
>
> > every time I see a conversation on this list that says something to the
> > effect of "we have xxx number of recipes that do this" or "if we make
> this
> > sort of change we'll have to change yyy number of recipes" I cringe. I
> ran:
> >
> > [msundius@msundius-lnx1 recipes]$ find . -type f | grep "\.bb$" | wc
> >   8581    8581  276766
> > [msundius@msundius-lnx1 recipes]$ ls -1 | wc
> >   2023    2023   18851
> >
> > 8500 recipes just doesn't seem like a scalable number of recipes to
> manage
> > w/ our development community. Its problematic for the following reasons:
> >
> > 1) making a change that affects compatibility is difficult if not
> > impossible
> > 2) most people working w/ embedded distros want only a small percentage
> of
> > this beast
> > 3) building involves bitbake parsing all of these recipes before going to
> > do
> > the tree of what actually needs to be built.
> > there are probably more complaints from the masses
> >
> > It seems to me that we need to decouple in a formal way the recipes from
> OE
> > (classes and config files) and from each other.
> > I am proposing that we do the following:
> > - that we define exactly what it means to conform to a particular version
> > of
> > the OE Recipe API (or whatever you call it).
> > - that we "fetch" recipes from well known repositories/mirrors (or
> locally)
> > in the same way we fetch tarballs.
> > - we parse recipes as we build the dependency tree.
> >
> > That way we don't have to look through the entire list 8500 recipes
> > (parsing
> > them all) before we build our tiny little embedded application that
> > controls
> > a refrigerator's ice making machine or whatever you make.
> >
> > For us, we simply don't use most of all of the recipes and I have found
> it
> > hard to manage the disparity of the entire official tree vs the recipes
> > that
> > we use. I have simply created my own (sub)tree that is a subset to the
> > greater tree.
> >
> > I also like the idea that we would be able to append our own
> configuration
> > data patches etc for selected standard recipes (that could be "fetched"
> > from
> > somewhere) so that we would not really have to merge all of those
> specifics
> > of our own system into the repository of recipes used by the whole world
> > (i.e. noone cares about the busybox config file we use or a patch to the
> > kernel to fix a dumb thing our HW engineers did). somthing akin to the
> > .bbappend discussion as of late
> >
> > I realize that this is off topic here. I also am not qualified to propose
> > how to implement such a solution. I'm just wondering if that might have
> > already occurred to any of us that there's a fundamental issue that
> > detracts
> > us from creating a truly independent build framework. I'm also not trying
> > to
> > be a complainer.. I've been thinking about this for a long time and I'd
> > like
> > to help... I'm just not that good  w/ python :]
> >
> > Back to the discussion at hand, If we have a (versioned) compatibility
> > standard for recipes then we could simply bump the number and exclude old
> > recipes until their maintainer or someone who needed it, got around to
> > upgrading the recipe.
> >
> > Mike
> >
> > On Sat, Jul 24, 2010 at 2:57 AM, Frans Meulenbroeks <
> > fransmeulenbroeks@gmail.com> wrote:
> >
> > > Dear all,
> > >
> > > The topic of legacy staging has been on the table for probably 8 months
> > or
> > > so.
> > > Still we have a lot of recipes that use legacy staging.
> > > This email tries to stir up the discussion on how to get rid of these.
> > >
> > > Most of the major recipes seem to be converted.
> > > Koen reported 53 recipes with legacy staging after building
> > > angstrom-gnome-image and openjdk. [1]
> > > This seems an indication that lots of common and actively used recipes
> > are
> > > converted.
> > > However there are still 1100+ recipes and about 150 .inc files that
> have
> > a
> > > do_stage rule [2]
> > >
> > > This indicates that quite some work is still needed.
> > > Let's have a look at the options. What I see as possibilities are:
> > >
> > > A: accept that we will have lots of recipes around that use legacy
> > staging
> > > B: update and test all recipes (at least up to the level that it is
> > > verified
> > > that the files stage properly after removing the legacy staging
> > > C: with a sed script or so remove all do_stage functions and hope the
> > best
> > > for it.
>
>>
>>
>> --
>> Christopher Larson
>> clarson at kergoth dot com
>> Founder - BitBake, OpenEmbedded, OpenZaurus
>> Maintainer - Tslib
>> Senior Software Engineer, Mentor Graphics
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
> > > D: remove the recipes that still use legacy staging as apparently
> no-one
> > is
> > > enough interested in them to update them.
> > >
> > > Let us now look at the pro's and con's of these possiblities:
> > >
> > > From the various calls to fix this that I have seen on the mailing list
> A
> > > is
> > > not really too desired.
> > >
> > > B would be nice, but is a hell lot of work. With 1100 recipes, 150 inc
> > > files
> > > and 5 minutes per recipe, this takes about 100 hours.
> > > Even with one minute per recipe it would be about 20 hours.
> > > Given that lots of the recipes for which this applies seem to be rarely
> > > used
> > > or are older versions of recipes that are not used any more, this seems
> > > somewhat a waste of time.
>
>>
>>
>> --
>> Christopher Larson
>> clarson at kergoth dot com
>> Founder - BitBake, OpenEmbedded, OpenZaurus
>> Maintainer - Tslib
>> Senior Software Engineer, Mentor Graphics
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
> > > Unless someone stands up as volunteer or someone develops an automated
> > > solution, I feel this is not going to happen.
> > > (and no: I feel no desire at all to spend hours and hours of my spare
> > time
> > > to convert recipes most of which I am very unlikely to use).
> > >
> > > C is a quick hack without warranty that the recipe is not broken.
> > > I've no idea how you feel about this, but in my opinion I'd rather have
> a
> > > legacy staging recipe which works than a non-legacy staging one which
> > might
> > > or might not be broken.
> > >
> > > That leaves option D. Of course removing all recipes that still use
> > legacy
> > > staging is not desired, as that would also mean e.g. removal of the 53
> > > recipes identified by Koen. [1]
> > > However, the idea has some merits. Lots of the recipes with legacy
> > staging
> > > seem to be old recipes. See e.g. the alsa-lib example [3]. By removing
> > > these
> > > at least the time and work needed for B would be less.
> > >
> > > Now how to proceed?
> > > Well that is the reason for this email.
> > > I would like to hear your opinions on this, so feel free to voice them.
> > > If there is consensus we can start deploying things. If not we might
> ask
> > > the
> > > TSC for some guidance.
> > >
> > > To start off the discussion let me give you my personal view.
> > >
> > > I would be in favour to remove all recipes that use legacy staging and
> > that
> > > do not fit into one of the following categories:
> > > - it is  the most recent version of the package that is build by the
> > recipe
> > > - it is not the most recent version but all more recent versions have
> > > DEFAULT_PREFERENCE = "-1"
> > > - it is pinned by a distro
> > > - it is a toolchain recipe (gcc, binutils, automake, autoconf and
> > probably
> > > glibc)
> > > - it is a kernel or u-boot recipe
> > > The rationale behind this is that it removes a lot of recipes (and
> hence
> > a
> > > lot of work converting).
> > > Note that the recipes are not gone. They will remain in the stable 2009
> > > branch and they can always be retrieved from git.
> > > So should someone for whatever reason need a recipe he/she can recover
> > it,
> > > fix it and put it back.
> > >
> > > After that we can make an inventory of the work re
>
>>
>>
>> --
>> Christopher Larson
>> clarson at kergoth dot com
>> Founder - BitBake, OpenEmbedded, OpenZaurus
>> Maintainer - Tslib
>> Senior Software Engineer, Mentor Graphics
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
> maining.
> > > If there are relatively few recipes remaining it will become a lot
> > simpler
> > > to find volunteers to clean up those.
> > > If there are many e.g. because an orphaned distro or machine pins lots
> of
> > > legacy recipes) we might consider a different scenario.
> > >
> > > This is my personal view, but ofc I would like to have a discussion on
> > this
> > > and hear other opinions so preferably we can come to a consensus.
> > > The only request I have is that if you advocate a certain solution that
> > you
> > > are willing to participate in realising that solution.
> > > E.g. it is easy to say that B is the desired scenario and that others
> > > should
> > > implement this.
> > >
> > > Best regards, Frans.
> > >
> > > PS: if the consensus is to start off removing the
>
>>
>>
>> --
>> Christopher Larson
>> clarson at kergoth dot com
>> Founder - BitBake, OpenEmbedded, OpenZaurus
>> Maintainer - Tslib
>> Senior Software Engineer, Mentor Graphics
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
> legacy recipes as I
> > > proposed above, I am more than willing to participate in that.
> > > and if someone has a good idea on how to automate identification of
> > > qualifying recipes (especially weeding out from the list, the ones we
> > still
> > > want to retain), I'd love to learn about that too.
> > >
> > > [1]
> > >
> > >
> >
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-July/021870.html
> > > [2]
> > >
> > >
> >
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-July/021901.html
> > > [3]
> > >
> > >
> >
> http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg08150.html
> > > _______________________________________________
> > > Openembedded-devel mailing list
> > > Openembedded-devel@lists.openembedded.org
> > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> > >
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
>
>
> I strongly share Michaels feeling and I have been pondering about solutions
too (including parsing when needed)

I was aware of the DEPENDS issue. workarounds for it could be
- split recipes in two , one part which only contains the DEPENDS (e.g.
similar to .inc where the DEPENDS is in the recipe and most of the rest is
in the .inc)
- only one package provided in a recipe so from the name it is clear what is
provided. eg. gcc_x provides gcc (and maybe some additional related packages
like gcc-dbg, gcc-doc etc etc)

Another option is to split the recipes dir in parts, so users can select not
to include part of it (e.g. I have no interest in opie recipes)

On my system parsing the 84xx recipes that we have (after touching a conf
file) takes 3 minutes or so.

Bringing the thread back to the topic:
I see no real interest into tackling removal of old style staging (or old
native recipes).
No opinions on how to proceed ?
If not, things probably will remain as they are.

Frans.

PS: I think part of the problem is that most recipes do not have a
well-defined owner who is responsible for maintaining them. I know we use to
have them  mentioned in the recipes. That had some issues, but at least it
was more clear who felt responsible for what, and it was also more clear who
to bother to fix a recipe (and it was more clear which recipes are orphaned
or become orphaned when the maintainer leaves).

Re: [RFC] get rid of legacy staging

[Koen Kooi]

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

On 27-07-10 12:19, Frans Meulenbroeks wrote:

> Bringing the thread back to the topic:
> I see no real interest into tackling removal of old style staging (or old
> native recipes).

It's hard to tackle that when OE is so broken you can't build anything,
as it is now due to the cross dir changes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMTrcjMkyGM64RGpERAqQyAJwLPNi6KtWSbPapnVOgwcZA4yz3lwCfb6l9
vDgKnV1RO8s78ac4b4iFRFY=
=GLFm
-----END PGP SIGNATURE-----

Re: [RFC] get rid of legacy staging

[Frans Meulenbroeks]

2010/7/27 Koen Kooi <k.kooi@student.utwente.nl>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 27-07-10 12:19, Frans Meulenbroeks wrote:
>
> > Bringing the thread back to the topic:
> > I see no real interest into tackling removal of old style staging (or old
> > native recipes).
>
> It's hard to tackle that when OE is so broken you can't build anything,
> as it is now due to the cross dir changes.
>

Au contraire!
This is an opportunity!

actually I think one of the easy things is removing do_stage functions that
only do an autotools_stage_all.
This is one (if done with some care) that does not seem to need extensvie
testing.
There are 400+ of them, but I seem to recall someone already did a patch for
this.

Frans


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFMTrcjMkyGM64RGpERAqQyAJwLPNi6KtWSbPapnVOgwcZA4yz3lwCfb6l9
> vDgKnV1RO8s78ac4b4iFRFY=
> =GLFm
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC] get rid of legacy staging

[Chris Larson]

On Tue, Jul 27, 2010 at 3:19 AM, Frans Meulenbroeks <
fransmeulenbroeks@gmail.com> wrote:

> PS: I think part of the problem is that most recipes do not have a
> well-defined owner who is responsible for maintaining them. I know we use
> to
> have them  mentioned in the recipes. That had some issues, but at least it
> was more clear who felt responsible for what, and it was also more clear
> who
> to bother to fix a recipe (and it was more clear which recipes are orphaned
> or become orphaned when the maintainer leaves).


I very strongly agree with this, but there have been issues with it in the
past, due to people leaving the project, vacations, hiatus, they become a
bottleneck.  But conceptually, maintainership seems like a very good idea to
me.  If I considered myself the maintainer of a set of recipes, I'd do my
best to ensure that they're always buildable and the recipes are always up
with current conventions.  *shrug*
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics