On Sun, 2012-01-15 at 16:13 +0000, Adam D. Barratt wrote: > It would be useful if queue-viewer could run debdiff on binary uploads, > in order to catch things like missing or new files and permission > changes. If anything interesting is found this could then be included > in the queue output.
As we never seem to get any further in that direction than saying "we really should do that" after an issue, or a d-i binNMU, some thoughts / debate points: - How should we invoke debdiff? We can avoid multiple debdiff invocations via "debdiff --show-moved --controlfiles=ALL --from base1.deb base2.deb --to new1.deb new2.deb" or, if we want to make the command line shorter, generate .changes files for the two sets of packages and then feed those to debdiff. In the latter case, we'd want to create symlink farms, as the .deb files would need to be in the same directory as the .changes files. - Is there a way we can make the wdiff output easier to review? We need to consider both on-screen display (presumably primarily via a web browser) and the possibility of mailing the result, as we do for source uploads. - Should queue-viewer always display links to debdiffs for every architecture, or only those where those is an "interesting" difference? What would be a useful UI for that? - What differences are we interested in? Some will always occur - version number changes from $old_source_ver to $new_source_ver (with adjustment for binNMUs); the addition of a "Source" header for a newly-binNMUed package; a change in Size / Installed-Size within a certain delta. - What should happen if the list of binary packages is different between the two versions? While still an exception, this happens often enough with e.g. firefox updates, that we need to consider it. Regards, Adam
