Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single
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 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 hadn't appreciated that, from your (legitimate) point of view, this
was a regression. I'm sorry.
> 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.
But, I'm still not sure which behavioural change you're talking about.
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:
> You might want to allow non-dgit users to use 'dpkg-source --commit',
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:
> if you think the bugs aren't going to arise for your package
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.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single
Hello, On Wed 22 Feb 2023 at 05:21pm -07, Sean Whitton wrote: > > 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 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. -- Sean Whitton signature.asc Description: PGP signature
Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single
Hello,
On Thu 23 Feb 2023 at 12:42AM GMT, Ian Jackson wrote:
> Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as
> implying --quilt=single"):
>> 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?
>
> Well, I'm a bit confused right now, but: I think a potential problem
> 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.
Okay, yeah, I guess we would have thought about having dgit do it at the
time and concluded that we couldn't.
>> 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.
>
> Hmmm. I am very reluctant to recommend a practice which will induce
> 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.
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.
> 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.
Yeah.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single
Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as implying
--quilt=single"):
> 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?
Well, I'm a bit confused right now, but: I think a potential problem
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.
> 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.
Hmmm. I am very reluctant to recommend a practice which will induce
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.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single
Hello,
On Wed 22 Feb 2023 at 09:45PM GMT, Ian Jackson wrote:
> Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as
> implying --quilt=single"):
>> 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?).
>
> 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.)
Yes, this is a good distinction.
> 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.
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.
> 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?
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
signature.asc
Description: PGP signature
Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single
Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as implying
--quilt=single"):
> 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?).
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.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single
Hello, On Wed 22 Feb 2023 at 01:28PM -07, Sean Whitton wrote: > This is still better than the previous situation because dgit will undo > some problems created by single-debian-patch (right?). 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 signature.asc Description: PGP signature
Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single
Package: dgit Version: 10.6 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?). -- Sean Whitton signature.asc Description: PGP signature
