On Fri, 2014-09-12 at 19:38 +0200, Ralf Corsepius wrote: > On 09/12/2014 05:09 PM, Mark Wielaard wrote: > > valgrind 3.10.0 was just released and I created packages for rawhide and > > f21. Then I noticed some packages include their own copy of valgrind.h > > (at least libsecret, gcr, libgnome-keyring, realmd, ipxe and pidgin). > Not directly related to your question, but ... > > Why do these packages do so and not use a global version?
I am not really sure. Probably because it is easier? Normally the macros defined in the valgrind.h (or memcheck.h, etc.) header files don't change. At least not in incompatible ways, just new architectures get added and new request types. The files are also explicitly marked as: Notice that the above BSD-style license applies to this one file (valgrind.h) only. The entire rest of Valgrind is licensed under the terms of the GNU General Public License, version 2. See the COPYING file in the source distribution for details. This file is for inclusion into client (your!) code. You can use these macros to manipulate and query Valgrind's execution inside your own programs. Maybe people misunderstand that to mean they have to include the whole file in their local source copy instead of just simply #include it? > What these packages are doing is similar to bundling and static linkage, > and suffers from similar consequences, such the issues you currently are > having. Yes, indeed. Should they add something like Provides: bundled(valgrind.h) I am not sure what the correct policy is in the case of a single (or a handful of) header files included as private copies. I was just going to file bug reports against the packages to request they either update the private copy (or ask upstream to) or remove them and add BuildRequires: valgrind-devel and just #include the system copy. Cheers, Mark -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
