So the question is: why does Valgrind install its internal headers and libraries, and a pkg-config file that references same? "Writing a new Valgrind tool"[1] doesn't mention them at all, and in a 2009 commit, Nicholas Nethercote said: valgrind.pc.in: try to make this more accurate. I doubt anyone's using it. It doesn't appear to be set up to handle dual-architecture builds. On the other hand, bug #307729 was filed against valgrind.pc in 2012, so I guess somebody *was* using it at least that recently. It's not really a good idea to ship this stuff in such an undocumented manner; I myself filed <https://bugs.debian.org/725223> asking for the internal headers to be removed, not having noticed the .a files tucked away in /usr/lib/valgrind/ (maybe I only looked in the /usr/lib/i386-linux-gnu/ tree?). Another bug related to this stuff is <https://bugs.debian.org/731228>, which requested an Arch:all package that would contain valgrind.h and the other client request headers so that other packages could build-depend on it without hardcoding a list of architectures to which valgrind has been ported. Unfortunately, this got backed out because: > While I still think this would be nice, it turned out to be a bit more difficult > to implement (basically the pkg-config file is generated at build time, and it > can't be created if the configure stage fails). So, you should probably either (a) stop shipping these files or (b) mention them in the documentation, both in "Writing a new Valgrind tool"[1] and in the README_PACKAGERS file. [1]: http://valgrind.org/docs/manual/manual-writing-tools.html
I believe they are there for people developing tools. The headers for people wanting to use valgrind (ie the ones with client request defs) are normally in the main valgrind package and the ones for people writing tools in a -dev or -devel type subpackage. Only the lattter have a .pc file I think.
What would (In reply to comment #1) > I believe they are there for people developing tools. The headers for people > wanting to use valgrind (ie the ones with client request defs) are normally > in the main valgrind package and the ones for people writing tools in a -dev > or -devel type subpackage. Only the lattter have a .pc file I think. Well, on Debian it can be inconvenient to build-depend on a package on only those architectures it's available on; you more-or-less have to explicitly list all of them in your build-depends. For example, the dbus package has this in its build-depends: "valgrind [amd64 armhf i386 mips mipsel powerpc ppc64 s390x]". If it did not list these arches, it wouldn't get built for any architectures besides those. (Granted, the only ones missing at the *moment* seems to be armel, kfreebsd-i386, and kfreebsd-amd64, but that's presumably because the release team have been on a removal spree; also, we generally like our packages to work without modification even on (say) debian-ports architectures.) So basically I'm thinking that the bulk of valgrind should be in one arch-dependent package named "valgrind", the internal headers, lib, and .pc should be in another arch-dependent package (possibly "valgrind-tool-dev"?), and the client-request headers should be in a third, *architecture-independent* package (perhaps called "valgrind-dev"?); then, things like dbus that want to use the client request headers could simply list this final package in their Build-Depends and not have to maintain their own list of arches that valgrind supports. Does that sound reasonable to you?
(In reply to comment #2) > list all of them in your build-depends. For example, the dbus package has > this in its build-depends: "valgrind [amd64 armhf i386 mips mipsel powerpc Why does dbus depend on Valgrind at all? Valgrind client request headers should only be needed for building dbus for debugging reasons, and this is definitly not the case when building packages for distribution?