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

[Robert Yang]

On 12/08/2017 10:18 PM, Alexander Kanavin wrote:
> 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?

Yes, since glibc would causes others failed to build, so I removed the commited
during upgrading, and then apply it back, I think that this is more helpful than
leave the failed commit there and causes others failed.

// Robert

> 
> 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
>