Code review comment for ~mkukri/ubuntu/+source/xserver-xorg-input-synaptics:merge
Revision history for this message
| Mate Kukri (mkukri) wrote | # |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
Hi Dan, thanks for the review.
> I see the changelog says "No change rebuild" but what's going on here is
> something different. If I diff the actual 1.9.2-1ubuntu1 version to this, it
> does show differences similar to what is shown in your change description. So
> this isn't a "No change rebuild" - if you debdiff source package for such an
> upload I would only expect a difference on debian/changelog. So the changelog
> should instead reflect that. What's going on here is a correction to a
> previous flawed upload, which is fine but should be noted in the
> debian/changelog file. What that should be really depends on the rest of
> what's going on.
As for as changelog goes, of course I'll go and fix that. I put that there because it was a no change rebuild on my machine, but in retrospect that is indeed wrong because the source package that was uploaded did not match my build of ubuntu1.
> > I know the Debian .diff.gz shouldn't really modify upstream files,
> > but the upstream git repo and tarball is not perfectly identical,
>
> Source repacking is a thing and intended for some problems of this sort, for
> instance if the upstream tarball has things that are believed to be non-
> distributable. Is that the case here?
What is going on is that the upstream git repository has extra files compared to the upstream tarball,
and these "modifications" are merely adding those to the files from the tarball (because of the packaging actually being based on upstream git).
This seems to be limited to "autogen.sh" and some extra README files. All of which appear to be under the same license as the rest of the package.
> > and Debian does the same thing.
>
> It really would be more common to patch these files instead of modifying them
> directly, even if the Debian version were to be doing it in a non-standard
> way. Is there a reason we can't patch these files here in the quilt flow?
I can do this if you prefer, however the packaging is based on the upstream git repository, so it would imply extra diff removing the files and adding patches, and diverging from Debian for what appears to me not much benefit in this case.