Bug#655976: queue-viewer: support binary debdiffs
On Sun, 2016-10-02 at 13:18 +0200, Julien Cristau wrote:
> On Tue, Sep 27, 2016 at 20:35:43 +0100, Adam D. Barratt wrote:
>
> > - 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.
> >
> I don't think length of the command line is a big concern?
I guess not, as we're not doing anything crazy like invoking a shell.
> > - 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.
> >
> If the html part could have some colors to show added/removed bits,
> that'd be nice.
Ack.
> > - 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?
Possibilities that come to mind:
- a new "binary debdiffs" column
- a "binary debdiffs" row in the upload information
> > - 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.
>
> Also adjusting for epoch, and binary packages with different versioning
> schemes from the source. diffpackages doesn't quite deal with that,
> yet...
Yeah, a little intelligence would be needed to catch all of those. We
can improve that as we go along of course.
> I think it's ok to leave filtering to a later date though, if we
> can get something it'll be better than the current "notice issues on the
> point release Saturday".
Indeed, I'm just wary of the queue-viewer output becoming too noisy and
either difficult to use (in case of the online version) or ignored (for
mails).
>From an implementation perspective, I had wondered if it was worth
trying to fit the binary methods in to the existing debrelease.debdiff
class which handles source diffs, but I'm not sure if that would just
make things more difficult.
Adam
Reply to: