On 12/15/2016 11:09 AM, Ben Finney wrote: > Control: retitle -1 python-coverage: install bundled third-party > ‘jquery.hotkeys.js’ library > > On 15-Dec-2016, Loic Dachary wrote: >> In the case of this javascript dependency, there is no reliable API, >> no backward compatibility and no releases. > > That sounds like you're trying to convince people to never use this > library :-) How did you reach those condemning conclusions?
:-) This is a useful file to copy/paste, I'm just saying it does not have the qualities one would expect from a packaged library. >> Do you acknowledge that packaging coverage.py with dependencies that >> are different from those provided in the upstream source may >> introduce bugs ? > > Certainly, any change to any software can introduce bugs. Why do you > ask whether I acknowledge that? Because I'd like to know what kind of testing/verification was done to verify that these changes did not introduce bugs. > > If I understand you correctly, you are asking in this bug report that > Debian's ‘python-coverage’ packages would bundle a third-party library > that is a slightly different version of the already-packaged > ‘libjs-jquery-hotkeys’. > > That isn't an option, as explained earlier. So we'll need to seek > another solution. I think correct solutions would include: > > * Remove the dependency. If the state of that code is as bad as you > say, this would be a good option; I hope we'll find that it's not as > dire as you portray above. > > * Make the dependency optional. This is recorded in the Coverage.py > issue tracker <URL:https://bitbucket.org/ned/coveragepy/issues/279/>. > > * Bring Coverage.py forward to use the latest API for ‘jquery.hotkeys’. > > There may be other options. What are your thoughts? The better option would be to have automated tests verifying the differences between the upstream files and the dependencies do not introduce regressions or behavior changes. The debian policy does not require that upstream files are replaced with packages that do not match the upstream files. In the case of jquery.hotkeys.js, the interface is different (the packaged file has hotkeys . and / to and they are not present in the file provided by coverage.py) and hotkeys won't work on all content editable areas. These are user facing differences. As a general rule, when files are bundled with the upstream sources, it is safe to assume they are unique to the upstream. Before replacing them with a packaged version they should be compared and each difference analyzed. If there are no differences, the files can be replaced by the packaged version. If there are differences and they did not modify the API nor the user interface, it may not be enough to decide they are not significant. Contrary to C ABI/API, javascript allows the user to reach into the internals in ways that are not documented or supported. This could be considered an upstream bug (in which case a bug report should be filed upstream) but it also means the upstream files cannot be replaced by the packaged files without introducing a regression. Cheers -- Loïc Dachary, Artisan Logiciel Libre
