[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#655976: queue-viewer: support binary debdiffs



Hi Adam,

thanks for getting this rolling.

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?

> - 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.

> - 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.

Also adjusting for epoch, and binary packages with different versioning
schemes from the source.  diffpackages doesn't quite deal with that,
yet...  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".

> - 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.
> 
I think big fat "Removed binary package(s)" and "Added binary
package(s)" warnings together with the debdiff for common packages would
be enough, at least initially.  Otherwise you'd have to manually tell
the tool which binary package was renamed to show the debdiff between
old and new.

Cheers,
Julien


Reply to: