On mar, giu 24, 2014 at 09:33:51 -0400, Samuel Bronson wrote: > Control: tags -1 + patch > > Simon McVittie <s...@debian.org> writes: > > > On 15/12/13 23:22, Alessandro Ghedini wrote: > >> 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). > > > > Thanks for looking at this, anyway. > > > > You could generate a stub .pc file from debian/rules on unsupported > > architectures, maybe, and install the header files (or stub versions > > where all the macros expand to nothing) manually? The .pc file format > > is hardly rocket science. > > 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, and 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). 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. 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. > 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). Cheers
signature.asc
Description: Digital signature
