Hi. Thanks for the report.
gregor herrmann writes ("Bug#1147543: git-debpush stumbles over .gitignore"):
> `dgit push-source' handles a .gitignore file in the tarball, which
> is not in HEAD in git, by adding a commit:
...
> git debpush doesn't handle this situation; all I get is a failure
> email _after_ the attempted upload:
...
> fatal: path '.gitignore' does not exist in
> 'caea8b14b213a4a16c5edfb95dca6de58a9d9b56'
Here, git-debpush made a tag saying
upstream-tag=upstream/0.63
upstream=20a43e5ec72752935a8c26137148a2beb8d41c29
According to the current tag2upload tag spec, that means that the
.orig tarball is supposed to be treesame to that tag and commit.
We could change the spec.
But one of the things that the user is supposed to be able to rely on
is that the source package contents is predictable from the user's git
tree. That makes it safe for the user to work solely in git.
We could relax this requirement for .gitignores. But that would mean
that the source package, and the canonical dgit git branch, would
contain arbitrary .gitignore(s) that are not visible in the user's
HEAD. That seems hazardous. While a .gitignore is "just" metadata,
it can be quite surprisingly change the way git behaves for a user who
is manipulating the package with git. See Simon's comment
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908747#47
Another thing we could do is change the behaviour of git-debpush, so
that it would specify some different tag and tree. But there is no
such tag and tree in this scenario (and I doubt we'd want git-debpush
to make one) - and git-debpush couldn't even detect this situation
without running pristine-tar locally.
The underlying difficulty is that in this situation, the .gitignore
contents are expressed only in the xdelta diff in the pristine-tar
branch. In general, this is a very bad way to convey intended source
package contents.
(dgit push doesn't have this difficulty, because it has the tarball
right there already. Mayabe the user ran pristine-tar to generate it,
but dgit can't detect that and in that case that's the user doing; to
run pristine-tar safely, the user ought to manually do the kind of
checks that the tag2upload service does. Most users don't, I bet.
See also my comments about the xz-utils attack.)
The other possible workaorund would be to elide the upstream
gitignores when making source packages, and canonical git branches,
like dpkg-source does. That would be a DFSG violation. (Yes, I am
saying that dpkg-source is automating DFSG violations - see below!)
> That's a bit unfortunate …
Yes.
The underlying problem is #908747.
We have been muddling through with various workarounds (including the
one in dgit push where it makes a .gitignore patch). But my analysis
above suggests that we have reached the limits of our ability to work
around the problem.
#908747 is 8 years old and such arguments as have been presented in
favour of the current behaviour are speculative, weak, and rebutted.
I think the next step would be to refer #908747 to the Technical
Committee. I'm not sure I have the effort for that myself,
particularly after the LLM vote, and past harassment on the TC list (!).
But I would be very happy if you were to make that referral.
Ian.
--
Ian Jackson <[email protected]> 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.
