Hi Simon, > > - With approach (A), when we make a change to gnulib-tool, we need to > > commit > > new expected test results, which is quite easy. No effort otherwise. > > - With approach (B), we will get failures for other reasons as well: when > > a gnulib module has changed in an incompatible way; when the git > > repository > > of P has moved; when package P itself is broken. Sounds like a > > continuous > > effort to hunt down (mostly) false positives. > > Right, I agree!
OK, then let's forget about (B). > I wonder when/if we could get rid of gnulib-tool.sh? I think this would be a reasonable time after having made the Python implementation the default. I expect every package maintainer to run 'gnulib-tool' at least once in two years and report problems if they occur. Based on this assumption, we could drop gnulib-tool.sh two years after having made the Python implementation the default. > Maybe we have to declare some features no longer supported if they > cannot be implemented easily in gnulib-tool.py... That's not the plan. Most features have been implemented for good reasons. There is nothing that we can't easily implement on the Python side, other than error behaviour. Bruno
