Re: Best way to patch a public header file before installation
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
Reply to: