Hello,

I think that it's very unfortunate that one of our flagship workflows,
dgit-maint-merge(7), now requires local git configuration, in the form
of 'git config --local dgit.default.quilt-mode single'.
Git configuration is a pain to automate.

I understand the issues with single-debian-patch, but most packages will
never run into issues, and in any case there's no doubt it's a bug in
dpkg, which can be fixed.

How about having single-debian-patch imply --quilt=single in the absence
of any other setting or command line argument for the quilt mode?
Then in the docs we would say that it is a good idea to use only the git
configuration value, but that this is another option if you prefer it.

This is still better than the previous situation because dgit will undo
some problems created by single-debian-patch (right?).

Hello,

Re-reading #1018984, I see that this is not right.

I still think we should have s-d-p imply --quilt=single, and present
both options in the documentation.

Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single"):

The usual reason for eschewing in-tree directions about quilt format
is that the tree can't (mustn't) tell you if it's patches-applied or
not.  I think it would be OK for the tree to influence *how* patches
are made (ie, choose between --quilt=linear, --quilt=single, etc.)

There is also the fact that it would have an effect on dgit's
behaviour for an NMUer, but I think that's OK for this.

So your idea has merit.

However, do we want to have people put single-debian-patch in the
source tree ?  That has such weird dpkg-source behaviours.

Ideally we would do something that would influence dgit, but not
dpkg-source.  So maybe we could put some *other* dropping in the
source tree?

Ian.

Hello,

Yes, this is a good distinction.

Right, but the pile of Emacs addons I maintain using dgit-maint-merge(7)
will never hit any of those behaviours.  So it's a high cost to impose
on someone in a position such as mine.

I'm reluctant to introduce something else like this when we already have
the git-debpush tags thing.  Hmm -- is there some reason why dgit
couldn't put information in those tags in the same way?

Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single"):
is that if the branch format is converted without making a tag, things
can go wrong.  I'm not sure precisely how we avoided this with
git-debpush; part of the answer might be that git-debpush always works
in split brain mode.
other tools to corrupt data.  Note that the corruption might be
experienced by downstreams (ie, people outside Debian) who are trying
to use dgit to manipulate packages from Debian.

Whereas inventing a dropping in debian/source/ seems straightforward
and precisely correct.  It's a description of the maintenance/update
practice that generated the tree you're working with, and (by
implication) how updates to it should be made.

Is there anything stopping us inventing an "unofficial"
debian/source/options entry ?
... tested it ...
It causes these messages:
dpkg-source: info: using options from dgit/debian/source/options: --wombat
dpkg-source: warning: --wombat is not a valid option for Dpkg::Source::Package::V1
which is probably too annoying.

Ian.

Hello,

Okay, yeah, I guess we would have thought about having dgit do it at the
time and concluded that we couldn't.

You might want to allow non-dgit users to use 'dpkg-source --commit',
though, if you think the bugs aren't going to arise for your package, or
are optimistic that dpkg will be fixed soon, and don't want to change
up the workflow later.

I think that we can come up with a wording that gives people enough
information to make an appropriate choice for their package, and, as you
prefer, leans in favour of not having single-debian-patch in d/s/o.

Yeah.

Hello,

I still regret that this change went into bookworm, and would like to
simplify things again.  I still think that this is a case where the cost
of correctness-in-all-cases is too high.

I think we can revert the behavioural change and come up with an
appropriate warning in the workflow manpage.  It might be relevant to
recommend users consider using source format 1.0, even.

I've looked at this again.  Sorry it's been so long.

Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single"):

I hadn't appreciated that, from your (legitimate) point of view, this
was a regression.  I'm sorry.
Are we talking about this, in 9.0:

  * Reject split brain quilt modes with single-debian-patch.
    (Previously this would malfunction; now we reject it.)

?  That doesn't seem likely since 9.0 was July 2019 and this bug is
February 2023.  But maybe that's the one.  If so, the commit is
75b7a4c72614 which says "Right now, this malfunctions in dgit: we do
not do the split brain stuff".  So although dgit tries to honour d/s/o
single-debian-patch (by invoking dpkg-source) it doesn't manage to do
it in the quilt modes where you evidently want it.

(Looking at the context, I think maybe this was a side effect of other
changes making this complicated to get right.)

#1018984 is scary reading, but doesn't seem to involve anything but
docs changes except

  * With dpkg single-debian-patch, pass --include-removal to dpkg-source -b.

but that doesn't seem like it's what is in your way.


Going back to possible options:

Re somehow discovering this information from git tags: since this is
the same branch format, just a different way of generating patches, it
seems like fishing it out of the last git tag would be possible.
My concern in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031793#25
"if the branch format is converted without making a tag"
seems misplaced.  But fishing this out of the tag in dgit still feels
very weird to me.  It's not a thing dgit ever does the rest of the
time (git-debpush does, but that's different).

You wrote, as an argument in favour of writing single-debian-patch:

I agree that this is desirable.  But the failure modes I previously
described in #1018984 are terrifying.  I'm particularly bothered by
"I was able to make a source package [where] as soon as you try to
edit *an unrelated file* dpkg-source craps out terribly".

I don't think we can have both your goal, of letting people
dpkg-source --commit and fold in their changes into an existing patch,
*and* my goal of not ever getting people into the terrifyingly broken
source package situation (or encouraging things that may lead to that).

You also wrote:

You can know that for the things *you* do to the package.  But, you
don't know what changes downstream users are going to try to make.  In
my experience, people further from centres of knowledge do
increasingly strange things.

I very much prefer, as an ideological position, to favour the
interests of downstreams, even arguably deragned downstream users,
over upstreams such as ourselves.


So I agree that something should be done.  I still think
debian/source/options single-debian-patch is too bad to recommend.

I'm not opposed to trying to honour it, even so.  Currently the
rejection is implemented in `build_maybe_quilt_fixup`, near l.6234.

I don't think we can use `quilt_fixup_git_singlepatch` in this case,
because dpkg-source wants to regenerate the patch each time, so we
must produce *our* patch with dpkg-source, or the source package isn't
a fixed point.

So we *have* to generate the patch with
`quilt_fixup_dpkgsource_singlepatch`.  AFAICT from the git history and
the source code, that currently just doesn't work in split brain mode
(presumably for reasons to do with playtree juggling etc.


I still think it would be better to invent our own dropping to control
this, and have it modify the default quilt mode.  That could cause the
fixup call to be `quilt_fixup_git_singlepatch` and wouldn't need to
interact with dpkg-source's ideas.

We've ruled out our own option in d/s/options, but we could have
debian/source/dgit-options containing `quilt-single-patch` or maybe
even `single-debian-patch` or something.


What a tangled web we weave.  I hope this is of some use.

Ian.

Sean Whitton [22/Feb 2023 1:28pm -07] wrote:

Things have improved since then.

In particular, we now think that dgit should honour git-debpush's quilt
modes stored in Git tags: that's #1111423.

We haven't discussed making dgit start honouring its *own* quilt modes
embedded in upload tags.  If we were to do that, then with regard to
*this* bug, there would no longer be a regression for our flagship
dgit-maint-merge(7) workflow, in that you wouldn't have to do any local
git configuration and wouldn't ever have to pass quilt mode options.

We would still have lost 'dpkg-source --commit' with single-debian-patch
but I think we are both okay with that.

Taking a step back, it would overall be simpler if dgit and git-debpush
worked the same way with regard to quilt modes embedded in tags: they
both defer to the latest one written by either of them unless overridden
on the command line.

So how about we extend #1111423 to making dgit read quilt modes out of
both its own tags and git-debpush's tags, and consider that to resolve
the regression I'm concerned about in this bug?

Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single"):

CCing that other bug.  This message is mostly about
   dgit: should do git-debpush-style quilt mode autodetection
(which FTR I agree with, but I think is nontrivial).
DEP-14 tags which contain the quilt mode information, which look
for these purposes exactly like tag2upload tags.

But, there is a complication.  dgit needs to support NMUs, uploads to
distro A taking history from distro B, etc.  A dgit-based NMU
(dgit-nmu-simple(7)) uses git history which may have maintainer tag
containing dgit metadata.  It might also have dgit-generated dsc
imports.  More generally, work done from the dgit view (from
dgit-repos, or from an archive/ tag) needs to *not* use the
maintainer's quilt mode.  It must default to --linear.

A maintainer who uses --quilt=single might git merge from the dgit
view.  If an NMUer used --quilt=linear, they would then have the
NMUer's DEP-14 and archive/ tags in their history pointing to the
previous upload, but we wouldn't want to switch their quilt mode.

I forget the details of the precise algorithm in git-debpush, but if I
remember rightly it is partly driven by in-tree information (eg the
changelog) and maybe some knowledge of Debian version number
conventions.  I think that's fine for git-debpush.

For dgit I think we need to think about this in a much more serious
way.  Ie, we should understand what the data model is, and try to
develop an algorithm which we can prove will DTRT.  (Or at least,
won't do anything too bad.)

I don't think we should try to guess whether something is using an NMU
git workflow by looking at Maintainer information, or version number
conventions.  That information is political, and doesn't necessarily
tell you what git workflow is in use.  We need to determine the git
workflow by looking at the git history.

I'm not even sure that my scenario of a --quilt=single maintainer
merging a --quilt=linear NMU is distinguishable, in the data, from a
co-maintainer decision to change quilt mode.

Yes.

If we can come up with a sound way for dgit to determine the quilt
mode automatically, then I think we should adopt the same algorithm in
git-debpush.

(Or to put it another way: any algorithm that is correct enough for
dgit's much wider range of use cases, is also corredct for
git-debpush.  But not vice versa.)

I think this is a fine plan for resolving #1031793, but having read
what I write above you may think it will be too difficult.

Ian.

Ian Jackson [04/Mar  6:31pm GMT] wrote:

All good points, I agree with the importance of the issues you raise
here.

Not sure quite what you mean -- too difficult such that we should look
for an alternative solution to #1031793?