Paul Wise <p...@debian.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 installed. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
