Summary: | Why install internal headers/libraries/.pc file? | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Samuel Bronson <naesten> |
Component: | general | Assignee: | Julian Seward <jseward> |
Status: | REPORTED --- | ||
Severity: | normal | CC: | josef.weidendorfer, tom |
Priority: | NOR | ||
Version: | 3.9.0 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
See Also: |
http://bugs.debian.org/725223 http://bugs.debian.org/731228 |
||
Latest Commit: | Version Fixed In: |
Description
Samuel Bronson
2014-04-30 02:06:39 UTC
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? |