On Sun, Jan 28, 2018 at 11:45:37PM +0100, Mattia Rizzolo wrote: > On Mon, Jun 01, 2015 at 10:40:12PM +0200, Sebastian Ramacher wrote: > > #787406 was reported against libav today. It was caused by > > debian/libavcodec-extra-56.lintian-overrides and > > debian/libavcodec-extra-56.lintian-overrides.ii386 with differing content. > > > > I think this situation could be detected by lintian and would be great if it > > could emit a warning refering to [1] (as pointed out by Jakub in the bug > > report).
I agree, but the present implementation captures too much: A single arch-specific override is not a problem, as long as there is no other arch-specific or arch-generic override with different content. Imagine a package that needs a particular override on x86 and thus ships the same override for amd64, i386 and x32. Lintian would now flag this non-problematic case. > Actually, the problem may be wider: debhelper has a more general feature > of allowing '.$arch' as a suffix to the config files, that works not > only for lintian overrides (even if most commonly it's used only for > lintian overrides and symbol files, from my experience). Indeed, I've seen it being used for maintainer scripts. Though for maintainer scripts we know that they get unpacked to architecture-dependent paths (indeed all control files are). Then there are files (like .install) that only influence what is being packaged. Only those that actually end up being shipped in the data.tar matter here. Ever seen $pkg.menu.$arch or $pkg.logrotate.$arch? > I believe you should check all files supported by the regular debhelper > tools that affects the content of data.tar.xz (that means, things like > d/libfoo.symbols.$arch should be ignored, and perhaps some others). Given the above, I think we should assume file types as "ok" unless we know better. Extending the flag list to other types like menu or logrotate likely makes sense, but I'd keep it as a blacklist rather than trying to enumerate which files are not problematic. Helmut
