On Sat, Aug 10, 2019 at 4:51 PM Russ Allbery <r...@debian.org> wrote: > > I don't think there was anything specific to > git-buildpackage there.
Isn't the whole problem specific to git-buildpackage? > The result is that the patches-applied Debian > packaging tree is then representable in Git, which did seem mildly > superior to recreating the directory in debian/rules if it had disappeared > due to a round trip through Git. I would prefer not to add such an obscure patch to 11,000 packages. Is it really sufficient to create the directories in d/rules? > I can think of a situation where it > could mask an obscure bug: if the upstream build system expects to be able > to write to that directory without creating it first, this will work > correctly if the upstream tarball is unpacked, the Debian unpacked over > it, and then debian/rules run. But if a Git import happens in the middle > of that process, the package will then fail to build. That is a bug in our tools, not in upstream's delivery. Besides, couldn't you patch the upstream build system? > Given that, I can see some merit to adding a file to that directory in the > Debian package or otherwise arranging for that directory to be recreated. Why not let 'dh' take care of it via a newly added d/empty-dirs? It would be more explicit and self-explanatory. > It's a kind of annoying problem otherwise since whether or not it's > reproducible depends on whether one checks the package into (or out of) > Git or just unpacks it directly, something that most people wouldn't > expect to make a difference. Exactly, it's a bug in our tools. Perhaps even in git. I am sure it's been discussed and discarded. > If [the tag] had gone away once I added a file to > that directory in the packaging, I would have been quite happy with the > tag and its recommendation. Let's not jump to conclusions, then. We will find a good solution. Kind regards, Felix