[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#907727: Empty directory is already present in orig tarball



Felix Lechner <felix.lechner@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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: