> On Aug 26, 2020, at 8:41 AM, Jan Beulich <jbeul...@suse.com> wrote: > > On 25.08.2020 12:37, George Dunlap wrote: >> As an explanation, there are a combination of things. You proposed A (remove >> the dependency), Ian proposed B (use move-if-changed), but we’re hoping to >> do C (have an external tree) before the next release. I haven’t had the >> time to look into either B or C (nor, unfortunately, to review Nick’s >> submissions to other parts of the code — sorry Nick!); but I’ve still been >> reluctant to go for A. >> >> I think basically, unless someone is ready to tackle B or C immediately, we >> should just check in Jan’s fix (or probably better, just revert the patch >> that introduced the dependency). It will be annoying to have to potentially >> fix up the generated golang bindings, but that puts the incentives in the >> right place. > > One additional aspect to consider is that I ran into the issue actually > in a 4.14 tree (because it just so happened that the timestamps of the > involved files were "right" for the problem to be hit), i.e. whatever > we decide to do will also end up needing backporting. To me this looks > to make A less attractive.
I don’t understand why? If it’s a regression in 4.14 functionality, we have to backport something to fix it one way or another. If we were going to leave the functionality the way it is, it might make sense to make it so that the dependency was triggered only on staging/master; the goal, after all, was to make sure that the generated files were updated when libxl_types.idl was updated during development. BTW, one way to prevent this from happening would be to add a version of the build to the Gitlab CI loop which would build out-of-tree and fail in a similar manner. If there had been such a test, this change would have been reverted immediately. -George
