Bug#907727: Empty directory is already present in orig tarball
On Sat, Aug 10, 2019 at 4:51 PM Russ Allbery <rra@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
Reply to: