Control: tag -1 wontfix
Hi. Your mails were interesting and I hope you don't mind me CCing my
reply to the bug so they can be recorded for posterity.
Sean Whitton writes ("Re: dgit and submodules"):
> On Mon 29 Jul 2019 at 11:24AM -04, Theodore Y. Ts'o wrote:
> > Hi there, I'm back with another question.
> >
> > I see that #726953 ("dgit fails with submodules") is tagged wontfix.
> >
> > I'm sponsoring package which uses modules, dwarves-dfsg, which uses
> > submodules. It builds just *fine* using "gbp buildpackage". dgit
> > blows up because lib/bpf is a submodule.
> >
> > It looks like the best answer for now is to give up on dgit for this
> > package. I tried working around the problem by using:
> >
> > dgit --quilt=nocheck gbp-build
> >
> > This did work, but then
> >
> > dgit --quilt=nocheck --overwrite --dump-run
Right, --quilt=nocheck turns off the early check but the result is
simply a .dsc which is nonidentical to your git tree so boom.
Submodules are intensely frustrating[1]. One way they are frustrating is
that it is not clear even what it means for a .dsc to be identical to
a git tree which has submodule references. Are the submodules
supposed to be populated ? My inclination is to say the answer is
"yes", but your own practice here seems to be "no" ?
> > blows up because the upstream tarfile has lib/bpf in it. (Remember
> > git submodule? This is a song about git submodule.... with apologies
> > to Arlo Guthrie. :-)
>
> It's possible that it could be supported by dgit using some kind of very
> complex split brain mode, but I don't think anyone wants to work on it
> for a while.
If there were a tool that would turn submodules into subtrees, dgit
could use that to fix up the submodules, during quilt fixup perhaps.
A design question we would have to answer is: is it OK for a DEP-14
maintainer view tag to refer to a tree with submodules ? Maybe this
is "ok" because the output from a submodule-to-subtree converter would
be a merge including the commits referred to by the submodules, so the
dgit tag would have as ancestors all the information needed to
populate the submodules. Maybe it is "ok" because it's de facto true
already. Maybe it's "ok" because actually we already don't impose any
un-waiveable requirements (from the consumer side) on what the DEP-14
tag points to.
Anyway, I am removing the wontfix tag because we have a plausible way
forward, even though (i) some design work is needed (ii) I don't plan
to work on it myself. To my mind "wontfix" is when you want to
discourage others from trying to contribute patches, and given our
much enhanced split brain mode possibilities, that's no longer
appropriate.
HTH.
Ian.
[1] I think they are nearly always the wrong answer. Usually they are
the worst answer. Even (especially) to the situation they were
specifically intended to address. They are simply too broken. Of
course this is of no help to you as a downstream if your upstream has
drunk the poison kool-aid.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
