On Mon, 2009-02-23 at 18:16 -0800, Russ Allbery wrote: > It's not warning because they're not ELF, and those are the only types of > binaries that it warns about. I figured as much. > 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. Well, you can execute PE files on Linux too, just need the right loader and libraries :) I agree about this though, probably all/most of the cases of PE executables in Debian would have to override this. There is also mono stuff to think about, there seems to be some mono exe and dll files in /usr/share: http://packages.debian.org/search?searchon=contents&keywords=.dll http://packages.debian.org/search?searchon=contents&keywords=.exe > 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. No, the Windows binaries are the same for i386/amd64. Yes, I really should split the package up a bit more. -- bye, pabs http://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part