Bug 9619

Summary:	Automate the process of updating meta patches in a recipe
Product:	[Build System, Metadata & Runtime] BitBake	Reporter:	Igor Stoppa <igor.stoppa>
Component:	bitbake	Assignee:	Joshua Lock <joshuagloe>
Status:	RESOLVED NOTABUG	QA Contact:	Francisco Pedraza <francisco.j.pedraza.gonzalez>
Severity:	normal
Priority:	High	CC:	bluelightning, jose.perez.carranza, poky.bs.watcher, poky.watcher
Version:	unspecified
Target Milestone:	2.2 M1
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	Yes (doc changes required)

Description Igor Stoppa 2016-05-11 13:28:47 UTC

Premise
=======
When a recipe is processed for building, it often entails obtaining sources from somewhere (example: repo on github) and applying a set of patches that are specific to the recipe.

Sometimes there is a need to modify the additional patches. This can be caused by upstream code changing and the local patches not applying cleanly anymore, or a need to add additional changes to the existing set of patches.

Problem
=======
Such process is cumbersome and can lead to errors when creating meta patches:
in practice one is generating a patch for the recipe that alters a patch file.

Proposal
========
If it was possible to enter devshell and see the correct set of upstream sources *with* the extra patches applied, through the same version control mechanism used by upstream, then one could treat the modification of the extra patches like if there was no devshell, all that would be visible is the combined stack of patches.

Once the changes are complete, then with some mechanism (for example triggered at the exit from devshell) the extra patches would be extracted from the current stack and used to refresh those contained inside the initial recipe, thus creating automatically the meta-patch(es)

Comment 1 Igor Stoppa 2016-05-11 13:36:31 UTC

This feature could be implemented with git, independently of what is the versioning system used by upstream and it would also make it impossible for the user to accidentally rewrite the history that comes from upstream.

Example:

1) obtain all the code from upstream

2) remove whatever versioning metadata might be present

3) use the entire upstream code as initial commit for a new git tree

4) git am all the extra patches coming from the recipe
   (would require some error handling in case the patches do not apply cleanly,
    maybe it would be better to just make the patches available but to not apply 
    them automatically)

5) let the user modify the stack of patches, with minimal risk that this affects 
   the initial commit

6) let the user export the extra patches used by the recipe, 
   overwriting the old set with the new set

7) after exiting from the devshell, either automatically or manually add the 
   changes to the extra patches as one or more meta-patches.

Comment 2 Paul Eggleton 2016-05-12 03:55:38 UTC

Have you looked at devtool (specifically the modify and update-recipe subcommands)? This is pretty much exactly what it does. See:

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#devtool-use-devtool-modify-to-enable-work-on-code-associated-with-an-existing-recipe

Comment 3 Igor Stoppa 2016-05-12 17:03:32 UTC

No, I was not aware of this functionality.

I do not remember noticing it, last time I went through the docs, but I might have just missed it.

Anyway, it does what I need, so this could be closed as invalid.

If I have specific issues, I'll create new ones against devtools.

It might be useful to add a short message when entering devshell, warning the user that devshell is more like the plumbing, while devtools is the porcelain.

Comment 4 Paul Eggleton 2016-05-12 20:47:51 UTC

Please do let us know if there are gaps in the functionality of devtool.

Regarding devtool vs. devshell, there's not really any connection there, although you might now use devtool as a substitute - right now devtool doesn't really give you special access to the execution environment for a task like devshell does. In future we'll have to figure out how to connect these two together, but it's not yet entirely clear to me how that would work though.