Bug#512645: lintian reports errors in package foo, because it does not honor files in the foo-data package, on which foo depends
Fabian Greffrath <greffrath@leat.rub.de> writes:
> Russ Allbery schrieb:
>> That being said, there is a possible hack that we can apply here that
>> may fix the common case of checking a *.changes file for a set of
>> related packages and on lintian.d.o. See the discussion in #456657 for
>> more details.
> Well, I have no clue about lintian internals, but isn't the check for
> the dangling /usr/lib/libfoo.so -> /usr/lib/libfoo.so.$SONAME in
> libfoo-dev packages a similar exception? At least it throws no error if
> /usr/lib/libfoo.so.$SONAME does exist in the libfoo$SONAME package and
> libfoo-dev depends on it.
Lintian intentionally doesn't check for dangling symlinks at all because
of this issue. See #217023.
>> This is why binary-without-manpage explicitly says to add an override
>> for this case, though.
>
> The binary-without-manpage warning is only the simplest one that crossed
> my mind. A more complicated example is realted to debian/foo.menu files.
In this case, I think you should keep the menu package in the binary
package and not move it to the data package. (Honestly, I would do the
same thing with the man pages as well.) There really isn't a need to move
everything into /usr/share, only the large data. Man pages and menu files
are small and don't waste much space in the binary package, and I would
just leave them there.
Otherwise, you can add an override here as well.
> Please, I really don't want to add a bunch of lintian overrides for
> reasonably packaged split-up packages. ;)
I understand your concern, but it's unlikely that Lintian is going to
change in any significant way in this area.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: