On Wed, Jun 21, 2017 at 10:27 AM, Ian Jackson
<[email protected]> wrote:
> Felipe Sateler writes ("dgit: can't handle debian branch with removed files"):
>> Control: retitle -1 dgit: can't handle debian branch with removed files
>>
>> Replying to the new bug because indeed this is a different problem.
>> I've found the cause. While my repo was faulty, I wonder if dgit can
>> be made to work better in this case.
> ...
>> OK, so now we can investigate what is wrong. Lets diff the first git commit:
>>
>> % git diff --stat master..d510ca798480f37fc567
>> debian/patches/debian-specific/lua-link.diff | 6 +-
>> doc/latex/doxygen.sty | 78 +++++++++++++++++++++++
>> frontends/CsoundVST/ScoreGeneratorVstUi.cpp | 169
>> ++++++++++++++++++++++++++++++++++++++++++++++++++
>> frontends/CsoundVST/ScoreGeneratorVstUi.h | 34 ++++++++++
>> 4 files changed, 282 insertions(+), 5 deletions(-)
>
> "master" is your Debian working branch I guess.
Yes, it is.
>
>> The diff in the patch is removal of `diff --git` lines generated by
>> gbp pq. The other files are not present in the master branch but they
>> are in the upstream tarball. It appears that at some point in the
>> history I removed them from the debian branch[1]. This breaks dgit's
>> expectations and thus the error we saw before. dpkg-source is fine
>> with this because it ignores file removals. Restoring these files
>> makes `dgit --clean=git sbuild` work.
>
> I think what you are saying is that your HEAD ("master", I think) does
> not contain these files. However, the source package that you are
> expecting to generate _does_ contain them, since there is no patch to
> remove them.
Correct.
> Unless something is done about it, this violates dgit's fundamental
> design principle, which is that the git tree you push should be
> exactly the same as "dpkg-source -x" on the source package.
>
> I think there are three options:
>
> 1. You could delete the files from the orig tarball (eg by repacking).
>
> 2. You could re-add the files to your master branch.
FTR, I've done (2) for this particular package. There was no need to
have these files removed.
>
> 3. You could add a quilt patch which deletes them.
>
> 4. dgit could automatically generate a quilt patch which deletes them
> and include it only in the dgit view.
>
> Obviously in some cases (1) or (2) would be desirable, but often they
> wouldn't. That leaves us with (3) or (4).
There is another option:
5. dgit mimics dpkg-source and ignores deletions and thus adds the files
back in the dgit view.
>
> What is your opinion about the relative merits of you adding the
> patch, in your own gbp branch, vs dgit "secretly" adding the deletion
> patch in the dgit view ?
Honestly, I'm not sure. In this case, dgit caught a real problem with
the repository. On other cases, it would be desirable to have dgit
perform step (5), so it mimics what dpkg-source does. I don't think
doing (4) is sane, because in effect that would mean that builds from
dgit are different from builds done by sbuild or pbuilder.
--
Saludos,
Felipe Sateler
