On mar, giu 24, 2014 at 07:05:12 -0400, Samuel Bronson wrote: > Alessandro Ghedini <gh...@debian.org> writes: > > > On mar, giu 24, 2014 at 09:33:51 -0400, Samuel Bronson wrote: > > >> Well, I think I've figured it out; there are really *two* packages > >> wanting to be split off, an Arch:all package and an Arch:any package. > > > > This doesn't really solve anything though. AFAICT e.g. dbus requires > > the pkg-config file to enable the valgrind thing, but > > valgrind-tools-dev would still be only available on the architectures > > already supported by valgrind, a2nd if dbus Build-Depends on it, it > > would still have to maintain the arch list. > > > > I could just move the headers to valgrind-dev and be done with it, but > > that in itself doesn't solve anything either unless all the other > > packages implement their own checks for the header files (making the > > pkg-config file pretty much useless). > > Yeah, I *did* notice that my changes won't just magically make things > better for dbus; it would, in fact, require patching configure.ac there > as well. However, what little mention I see of the pkg-config file on > valgrind's bug tracker is skeptical about it's usefulness as well; my > proposal certainly isn't making things any worse. > > Also note that, as far as I can tell, the pkg-config file was never > actually intended for use with the client request headers in the first > place, but only for use with out-of-tree tools. It is, however, hard to > tell for sure when both the pkg-config file and out-of-tree tool > development are completely undocumented. > > > Considering that the last > > "transition" (having all the valgrind build rdeps not Build-Depends on > > valgrind on armel) took months to complete, this will likely take a > > lot more of both time and work for very little gain... I'd rather > > spend that time on something else. > > I'm certainly not trying to do anything that will lead to more such > pain; quite the opposite. > > > All in all, I don't think these patches are worth the effort. > > > > A real solution would really be to have Debian packages stop > > Build-Depending on valgrind in the first place. There's no point in > > enabling the valgrind support in "production" builds for the end > > users. Those facilities are meant to be used by the developers of the > > software not their users. > > Actually, for libraries, such facilities can also be important to any > developers using those libraries in other software; if, for example, not > enabling valgrind client requests at build time will result in valgrind > reporting false errors in any program that uses that library, that could > get majorly annoying to people developing against the distro version of > that library. > > (It's quite possible, however, that libdbus is not actually one of those > libraries.)
Ok, so, I just checked how all the reverse build deps actually use valgrind:
* abiword: checks for valgrind/memcheck.h, but runs valgrind at build.
* alleyoop: requires valgrind at build.
* dbus: uses pkg-config.
* diod: runs valgrind at build.
* gsasl: runs valgrind at build.
* gss: runs valgrind at build.
* jq: runs valgrind at build.
* libdrm: uses pkg-config.
* libtest-valgrind-perl: runs valgrind at build.
* mpich: checks for valgrind/{memcheck,valgrind}.h.
* pypy: checks for valgrind/valgrind.h.
* qpid-cpp: runs valgrind at build.
* re2: checks for valgrind/valgrind.h.
* rhmessaging: runs valgrind at build.
* shishi: runs valgrind at build.
* simgrid: checks for valgrind/valgrind.h, probably runs valgrind at build as
well.
* starpu: checks for valgrind/valgrind.h.
* swi-prolog: checks for valgrind/valgrind.h.
* valkyrie: doesn't seem to require valgrind at build at all (???).
* xserver-xorg-video-intel: uses pkg-config.
(note that there may be errors).
Most of them run valgrind during build (mostly for testing AFAICT) and there's
nothing we can do about them (those are the packages that should probably stop
build-depending on valgrind).
Of the others, the ones that use pkg-config are dbus, xserver-xorg-video-intel
and libdrm, so we are in a pretty good position I think. They need to be fixed
before we do the switch though. All the others could simply switch to
valgrind-dev without further changes.
Cheers
signature.asc
Description: Digital signature
