Hi Russ, On Fri, Oct 25, 2019 at 1:40 PM Russ Allbery <r...@debian.org> wrote: > > To me, an override implies that Lintian is wrong, and I don't think it > is.
Why did you file a bug report? Please use an override. :) Joking aside, I do not think you are right. An override indicates the maintainer will not address something. When Lintian is wrong, people file bug reports. > (Whether the tag should exist is a different question; not all > problems are worth fixing.) The tag is not well-named, but its assertion is undisputed: The upstream sources contain an empty directory. Since your upstream is gone there is nothing you can do about it. You should override it (caveat below). > It's otherwise unactionable by the maintainer. It is actionable in that we can contact upstream (if the project is alive), but it will not improve the relationship. The tag is a widespread problem in the archive and a nuisance to many people. The tag should be removed. May I please retitle this bug? > It's bad practice to ship empty directories > in tarballs precisely because they're not representable in Git (and > generally have a tendency to get lost in various ways). I do not think it is necessarily bad practice to include empty directories in tarballs, although I would not do so personally. They are superfluous and should be ignored. If git, pristine-tar or other tools cannot deal with them in ways that work for their users, those are bugs over there. > It means that if anything relied on the directory existing, the directory > would be recreated by unpacking the source package and whatever relied on > that would succeed. Lintian can technically suppress the tag when a file is added the way you describe (by comparing the patched index against the unpatched index), but it would go against the spirit of the tag: Upstream shipped an empty folder. No maintainer addition can change that. As a side note, I disagree on the use of a placeholder. If the tag is not removed, I would use an override instead. Kind regards Felix Lechner