[oe] [RFC] get rid of legacy staging

Sat Jul 24 14:35:25 UTC 2010

2010/7/24 Martyn Welch <martyn at 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 at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>