On Thu, Nov 8, 2018 at 3:20 PM Mathieu Malaterre wrote: > Long story short, I believe this fixes the symptoms and not the actual > bug. I would even go one step further and make that arch specific > include be restricted (Debian policy) to only a subset of packages > (gcc, libc...), since I fail to understand why there would be arch > specific information in public header (obviously for a package not > dealing with low level arch specific).
On my system most of them look fairly low-levelish (see below). The dedup.d.n service and the multi-arch hinter can tell you when there are the same/different header files in the same place on different arches. https://dedup.debian.net/ https://wiki.debian.org/MultiArch/Hints > In my case, and I suspect in the vast majority of packages, this is > just lazy programming where a public header contains an implementation > detail that was used during the build but is meaningless to expose to > the final user. I think it would be interesting to explore this and or add some code to the multi-arch hinter to show header diffs between arches in /usr/include and the multi-arch subdirs of it. $ find /usr/include/x86_64-linux-gnu/ -print0 | xargs -0 dpkg -S | cut -f 1 -d: | sort -u libc6-dev libcurl4-gnutls-dev libexpat1-dev libffi-dev libgmp-dev libgpg-error-dev libjpeg62-turbo-dev libpython2.7-dbg libpython2.7-dev libpython3.6-dbg libpython3.6-dev libpython3.7-dev libssl-dev libstdc++-7-dev libstdc++-8-dev libtiff5-dev linux-libc-dev qtbase5-dev ruby2.5-dev -- bye, pabs https://wiki.debian.org/PaulWise