Sean Whitton writes ("Bug#977845: dgit: unhelpful behavior in case previous
upload contained new upstream release"):
> It can't distinguish between stuck in some dak queue vs. actually
> rejected, though?
dgit doesn't currently distinguish that. Mostly because I thought the
information is not available.
> I must be missing something here, because I don't see why the rejected
> orig.tar is needed. apt-get source will get you the orig.tar for the
> version actually in the archive, which is what you want to base your
> work off?
Well, that depends. dgit (currently) takes the view that in this
situation you should start from the version in git rather than the
version in the archive.
This is in large part because if you do "dgit clone" in the period
between "dgit push" and archive publication, you probably didn't want
to revert what the last uploader did.
I hesitate to put it like this, but: it is difficult to represent the
Debian archive in something moderately sensible like the git data
model, because the Debian archive is slow[1], opaque[2],
capricious[3], and racy[4].
Ideally the situation I would like is that if someone does dgit push,
and has the package REJECTed for some reason, their co-maintainer
should be able to fix it without having to do more than "dgit fetch",
hack hack hack, "dgit push". For this the co-maintainer needs the new
orig, not the one in the archive.
If a dgit-clone-using NMUer wants to upload from the last ACCEPTed,
either the git history has to diverge (and then what?), or the NMUer
has to make a pseudomerge which effectively reverts the
new-source-package upload.
This is all quite a mess. I think it's a worse mess to try to go
backwards, than to treat the uploaded-but-REJECTed version as the
baseline.
Ian.
[1] Several hours from upload to visibility in ftpmaster data API, in
the best case. Significant fractions of a year in the worst.
[2] As I understand it, you can't tell what's queued and whether
things are held back, or rejected, or what.
[3] Software can only do a very poor job of predicting whether a
particular package will go via the fast path, or the slow path of
NEW, or the very slow path of sitting in NEW for months while
people procrastinate and/or argue.
[4] Proper use of the Debian archive data model requires external
synchronisation on a per-source-package basis, to avoid lost
updates. This is because the update operation does not guarantee
that of multiple concurrent updates, at most one will return
"success" for the synchronous result of the upload attempt. In
dgit's data model, this synchronisation is provided by the
dgit-repos git server. In the trad Debian data model this is
provided by unstructured and manual human coordination.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These 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.
