Felix Lechner <felix.lech...@lease-up.com> writes: > I don't think this is a bug in Lintian.
> The source tarball xfonts-jmk_3.0.orig.tar.gz contains an empty > directory 'neep/ascii/': > $ dget > http://deb.debian.org/debian/pool/main/x/xfonts-jmk/xfonts-jmk_3.0-22.dsc > $ tar tf xfonts-jmk_3.0.orig.tar.gz > . . . > jmk-x11-fonts-3.0/neep/ > jmk-x11-fonts-3.0/neep/Makefile > jmk-x11-fonts-3.0/neep/Makefile.chardesc > jmk-x11-fonts-3.0/neep/Makefile.fonts > jmk-x11-fonts-3.0/neep/Makefile.fonts.in > jmk-x11-fonts-3.0/neep/Makefile.neep > jmk-x11-fonts-3.0/neep/ascii/ <<<<<<<<<<<<<< > jmk-x11-fonts-3.0/neep/fragments/ > jmk-x11-fonts-3.0/neep/fragments/Makefile > . . . > That triggers the tag when the file index for the orig tarball is examined: > > https://salsa.debian.org/lintian/lintian/blob/master/checks/cruft.pm#L450-451 Yes. That's the bug report. :) I would like Lintian to stop complaining about this when a file is explicitly added to that directory by the packaging. It's otherwise unactionable by the maintainer. > The comment in the tag description [1] about adding a placeholder to > the directory "as needed" applies to upstream before they ship the > orig tarball. Adding placeholder solely to your debianized sources > will not help. Why not? Or, to be more precise, I understand that it doesn't suppress the Lintian tag (hence the bug report), but why is that not a reasonable solution to the underlying problem that prompted Lintian to complain about this in the first place? The directory is now representable in Git and other directory-unaware views of the Debian package, since it now has a file in it. Maybe I should say explicitly that I think of Lintian as a linter for the *Debian packaging*, not a linter for the upstream package, so I'm a little dubious of tags that report purely upstream problems the Debian packager cannot fix without changing upstream. > With upstream defunct, wouldn't a Lintian override, or perhaps even a > repacking of the source, be good options for you? I can add an override if I need to, but I do feel like this tag is wrong in a way that Lintian *could* get right with more data. I tend to report those as bugs rather than adding overrides (as opposed to cases where I can't imagine a way for Lintian to be able to do better). The tag is only pedantic, so it's not any sort of urgent or important bug and I totally understand if you don't think it's worth fixing, but I'm not sure what Lintian could reasonably expect me to do about it other than what I already did. Surely this isn't important enough to warrant repacking the upstream tarball and thus breaking verifiable provenance? -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
