Bug#516858: lintian: false negative arch-dependent-file-in-usr-share (nsis)
Paul Wise <firstname.lastname@example.org> writes:
> NSIS contains the following architecture-specific files in /usr/share.
> These are all binaries for Microsoft Windows built with the mingw32
> cross-compiler we have in Debian. nsis is a tool to create installers
> for Windows applications and so it needs some Windows binaries to make
> those installers work. These files are architecture specific (win32) but
> currently the files are stored in /usr/share/nsis since that is where
> upstream puts them. I think lintian should warn about these
> Win32-specific files being in /usr/share. I'll be overriding the
> warnings though, until I can figure out where to install them (Debian
> needs multi-arch support too) and patch upstream appropriately.
> $ find debian/nsis/usr/share -type f -print0 | xargs -0 file | grep PE32
> debian/nsis/usr/share/nsis/Bin/RegTool.bin: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
It's not warning because they're not ELF, and those are the only types of
binaries that it warns about.
Hm. I'm somewhat torn on this -- my guess was that whenever there are
non-ELF binaries in an architecture-independent package like this, it's
most likely that they're for some purpose that doesn't make them *really*
architecture-specific. For example, firmware for embedded devices, which
from the perspective of the host system is legitimate /usr/share content.
Since they're not ELF, we know that they're not just misplaced compiled
helpers or libraries, since they're not executable directly on the host.
However, in this case, does nsis need to use different binaries for i386
versus amd64, including among these Windows binaries? If that's the case,
then indeed, we should warn about that because you then can't share
/usr/share between an i386 and an amd64 system that both have nsis
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>