The Automatic Upgrade Helper has the ability to do recipe upgrades, but quite often the process of recipe upgrading requires fixing/updating associated patches (and possibly adding new ones), which is an interactive process. We have the infrastructure for making this easier in devtool, so it would make sense to add the ability to start a recipe upgrade from devtool (or finish an upgrade that has been started by the AUH and emailed to the maintainer for fixing/review).
For the upgrade flow i propose, upgrade -t version source validate version/source download source copy old recipe to new recipe / handle include files update license check sums get a list of current patches remove all patches patch cycle (if applies) apply patch - if not apply did a interactive action maybe remove or rebase end patching test recipe/deploy
I had assumed it would be: devtool upgrade recipename [-V version] This would do all of the steps before "test recipe/deploy", leaving you with the upgraded recipe in the workspace layer once all patches have been dealt with. If you then do devtool update-recipe it would then replace the original recipe with the upgraded one. We already have pretty much all of this logic in the AUH though, right?
(Oops, I missed out the source tree path parameter in the above.)
(In reply to comment #3) > (Oops, I missed out the source tree path parameter in the above.) (In reply to comment #2) > I had assumed it would be: > > devtool upgrade recipename [-V version] > > This would do all of the steps before "test recipe/deploy", leaving you with > the upgraded recipe in the workspace layer once all patches have been dealt > with. If you then do devtool update-recipe it would then replace the > original recipe with the upgraded one. > > We already have pretty much all of this logic in the AUH though, right? Almost yes the AUH does not handle patches because it requires an interactive action of the developer.
Right. For the patch handling, devtool's patch application code uses our normal do_patch logic - which means we may be able to get away with setting PATCHRESOLVE = "user" for that (you'd have to try it though, I don't know how well that works in the context devtool runs it).
(In reply to comment #2) > I had assumed it would be: > > devtool upgrade recipename [-V version] > > This would do all of the steps before "test recipe/deploy", leaving you with > the upgraded recipe in the workspace layer once all patches have been dealt > with. If you then do devtool update-recipe it would then replace the > original recipe with the upgraded one. > > We already have pretty much all of this logic in the AUH though, right? Paul, after spending some time I got to the conclusion that we should use the AUH code for this feature (as you mentioned before). We have two ways, 1) taking the relevant code from AUH and place it into the poky's script/lib/devtool folder or 2) from devtool call the AUH app. Of course, 2) implies having the AUH repository somewhere on the host machine, making devtool dependent of AUH. I would go for 1 at this moment, but this means that we would have duplicated code, something not really wanted. Let me know what you think.
I think it has to be #1, but I would like it to be done in a way that the AUH code gets updated to make use of the new code brought across at the same time, so we don't end up with any duplication. This should also be an opportunity to have the AUH code use the functions in recipeutils to make changes to the recipe files rather than using its own implementation as it does now. Can you work with Anibal on that?
(In reply to comment #7) > I think it has to be #1, but I would like it to be done in a way that the > AUH code gets updated to make use of the new code brought across at the same > time, so we don't end up with any duplication. This should also be an > opportunity to have the AUH code use the functions in recipeutils to make > changes to the recipe files rather than using its own implementation as it > does now. Can you work with Anibal on that? Paul, I finished this task. On Monday, I will review it with Anibal. I do not want to send the patch until we review it and create also some tests. At the end, I did not use the recipeutils library, so code is almost as the AUH code at this point. Future improvements should use the latter library and AUH should call devtool for recipe's upgrade operation. I am afraid I can make it for 1.9M2, but next week this work should be done.
The implementation is currently being review by the AUH maintainer (Anibal Limon). Sending the final patch to the OE-Core list this week.
An RFC patch sent to the ML, waiting for comments. Subject: [PATCH 0/1][RFC] devtool: Upgrade feature From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com> There are several approaches when upgrading a recipe and on this patch it was decided to reused the code from the auto-upgrade-helper [1] and ported it into the devtool. There are several pending tasks as described in the patch's description. The progress of this feature is being track on [2]. [1] http://git.yoctoproject.org/cgit/cgit.cgi/auto-upgrade-helper/ [2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=7642
V1 patches had several comments from Paul, so It will take around 10 days to complete.
V3 set of patches sent to the ML.
Patch now in master branch (8be95c5) http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=8be95c5fbe6ad970943edabe288fd47d1dcac288
Hello, Tested on master with d302c98822efe2cb78a63b620aed1b94b4ed4a68 on Ubuntu 15.04 To test, i just reproduced the related oe-selftest testcase devtool.DevtoolTests.test_devtool_upgrade Marking as verified