Hi!
On Fri, 2016-01-29 at 02:17:47 +0000, Ian Jackson wrote:
> Guillem Jover writes ("Re: dpkg-source and gitish patches"):
> > > Having said all that:
> > >
> > > Now that are relying on gitish diffs, are there any plans to make
> > > dpkg-source able to represent binary diffs, and file removals ?
> >
> > Given that we have bitten the bullet on this (at least for now), I
> > was intending to bring up supporting git-style diffs natively in
> > dpkg-source, I've just not had the time to get to it yet. If you'd
> > like to work on that, that would be great.
>
> You mean, to have dpkg-source apply diffs itself, rather than relying
> on patch ?
Not necessarily in its entirety.
For starters I'd like dpkg-source to validate the git-style extended
headers by itself, to make sure we only allow things we want (those
defined in git-diff(1) “GENERATING PATCHES WITH -P”).
Acting on those extended headers when patch(1) does not, would allow to
extract these source packages regardless of the host system, which in a
way would solve the concern you brought up here.
For binary diffs, as long as patch(1) does not support them, and in case
they'd get documented, we could want to make dpkg-source support them by
itself, so that it could be used with older patch(1) versions/programs.
Although doing the acting by itself on those two cases poses the question
of how to handle the case when patch(1) does (or starts) supporting those
features natively, and we might end up performing the work twice and
possibly failing. One solution would be to analyze the patches, record
the extended headers and binary patches, strip those and massage the
patches so that they can be applied by a traditional patch(1), while
we let dpkg-source handle all the extended stuff by itself. But we'd
let patch do the bulk of the work, as I'm not sure reimplementing
patch(1) would be the best course of action here.
Thanks,
Guillem
