Simon Josefsson writes ("Bug#1105766: [tag2upload 207] failed, git2cl 1:3.0-3
[and 1 more messages]"):
> Nice example! It is just different in Sid vs experimental, I’m not sure
> there is any rule against this situation? But it is sub-optimal. I’m not sure
> other tools doesn’t have this issue too.
I think tag2upload created this situation. (It's not a very
desirable one.)
The t2u service ought to have found the existing .orig and reused it,
when it processed your upload to experimental. Instead, it didn't
find it, and then it made a new .orig.tar.xz with git-deborig and
uploaded that.
I think the possibility that this situation can arise means I will
have to implement the a complicated algorithm for orig finding.
Something like this:
* Retain the existing dgit fetch. We need the output of this anyway
because dgit push-source uses it. Doing it separately at the
beginning only costs a 2nd ftpmaster API query dsc_in_suite and a
2nd no-op git fetch.
In a normal NMU targeting the same suite this should always work,
unless maybe the current thing in sid is very new.
* If we don't now have any origs, look to discover existing origs
with a file_in_archive query. Hopefully we find precisely one
.orig.tar.* and possibly some .orig_foo.tar.* (only one of each).
* Thus having determined by API calls what origs we want, we attempt
to obtain them. If this does not work I think we must fail.
* If we don't discover any matching origs then we know we need to
make a new orig and use git-deborig, using the upstream= from the
tag.
* If we discovered some matching origs but there were stems for which
there were several files with the same stem, we don't know which to
choose. I don't see anything other to do but fail in this case.
I will think about this some more and maybe implement it tomorrow.
Ian.
--
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.
