[yocto] [PATCH 08/12] upgradehelper.py: clean repo only once when recipes are specified

Alexander Kanavin alexander.kanavin at linux.intel.com
Fri Dec 8 06:18:47 PST 2017


On 12/08/2017 04:00 AM, Robert Yang wrote:
> 
>> I'm not sure, the logical *without* this patch is:
>> 1) Do the commit when succeed or failed.
>> 2) git format-patch
>> 3) Remove the commit if failed, and leave the commit there if succeed
> 
> Sorry, "remove the comit if failed" is added by this patch, and why I 
> did this
> was because:
> $ auh glibc less bash gzip bzip2
> 
> All of them will be failed to upgrade if glibc fails since others 
> depends on
> glibc, so leave a failed commit in the repo would cause troubles when 
> upgrade
> multiple recipes, so we have to remove it when failed to let others can 
> upgrade, and then apply the failed commit back (if -f is specified) 
> after all of the
> recipes are done.

In my branch I've changed the approach altogether. Here's how it works:

1) attempt to upgrade the recipe using 'devtool upgrade'.
2) If that failed (usually because custom patches couldn't be 
auto-rebased), save the diagnostic info and move to the next recipe.
3) if succeeded, create a commit with changes and try to build the recipe
4) save the build diagnostic info (regardless of whether build succeeded 
or failed) and move on to next recipe

So two things happen:
1) commits are never removed, only created, even if the recipe then 
fails to build
2) after AUH is done, it produces a sequence of update commits and 
information on what couldn't be updated, and what couldn't be build. The 
maintainer then can choose to fix the build failures, or take the 
commits that cause build failures out of the branch or revert them. AUH 
does not anymore manipulate branches or commits.

I think it's a simpler and easier to understand approach. Yes, this 
means that an updated recipe that is close to the root of dependency 
tree can cause a cascade of build failures (e.g. glibc), but the update 
commits for everything else will still be created, and the maintainer 
can easily revert the failing updates, and re-run the build. What you think?

I can publish the code for you to look at, even though it's still work 
in progress, and I'd like to fix up a few more things first.


Alex



More information about the yocto mailing list