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.) >> We had actually stopped installing the internel headers entirely >> because I (Samuel Bronson) failed to notice that, while out-of-tree >> tool development *is* entirely undocumented, the requisite libraries >> *are* actually shipped. > > Well, we could just not install the *.a libraries. It's not like they > are of any use, and it would lower the valgrind package size by ~15MB > out of 90. > >> Note: I went for ages with no valgrind-dbg installed, and I'm not >> sure I've ever actually *seen* the warned-of issues. > > So why are you moving the symbols back in the valgrind package (by > disabling the stripping)? The whole point of having a seprate > non-Depends -dbg package is to let users not have to install the 200MB > of valgrind libs debug symbols, if you move them back into valgrind > it'd be like having a Depends on valgrind-dbg in the valgrind package > itself (thus making the whole exercise useless). Hmm, I see what you mean; it does seem to add ~140000 to the "Installed-Size" field. I guess I should've looked more closely at that before sending; that's obviously way too much space to blow trying to combat a problem that I'm not even certain actually exists anymore. (That patch was basically an afterthought anyway.) -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
