Hi, 2012/2/5 Jakub Wilk <[email protected]>: >> So I should remove "Multi-Arch: same" line from the control and that's it, > > Yes, that's the simplest way to fix it. > [...] > If you are feeling adventurous, you might want to keep M-A:same and make the > header file identical across architectures, e.g. by exploiting the fact that > GCC defines the __BYTE_ORDER__ macro.
Do you recommend this? I don't like to diverge from upstream if there's no compelling reason to do so, especially if they are not quick to attend these kind of requests and so we have to carry patches for ages. Also, is this macro supported by other compilers which can become more mainstream in the near future? >> Also, is there any way for maintainers to discover this in advance, before >> uploading packages? > > Nothing bulletproof. > > What I did for my packages, was to build the package for two architectures > (i386, amd64), unpack the resulting .deb (with dpkg --raw-extract) and then > run diff against unpackaged directories. But of course this procedure > wouldn't detect anything for libogre-dev, as i386 and amd64 are both > little-endian. > > That said, the existence of *.h.in files in the source package could have > raised your suspicion. If header files (or any other files, for what it's > worth...) are generated at build time, there's a chance that their contents > will be architecture-dependent. Got it. What about pkg-config files? Is it only an issue if they have different content across architectures, or the mere fact of being shipped in a /usr/lib/TRIPLET/pkgconfig dir renders the package "non-Multi-Arch: same"? Probably there's an obvious answer for you, but I'm still a bit confused about some Multi-Arch matters. >> Or after uploading, a kind of check like lintian or piuparts? I haven't >> seen any error related to this in the PTS interface and the reachable >> services from it. > > > A while ago I announced existences of a tracker for problems like that[0] > (which I'm use to file bugs when I'm bored :P). So a way to generate this is, after building in the buildd machines, download all -dev packages and unpack them in different dirs for arches, then diff them? That's what I'm trying to do right now, to see the exact differences in all of the architectures. > It's not connected to the PTS, though. > > [0] http://lists.debian.org/debian-devel/2011/11/msg00508.html So if it's reliable, it would be a good idea to add it to some of these tools :-) Cheers. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
