On 09/12/2014 10:53 PM, Mark Wielaard wrote:
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?
Possibly. I am not sufficiently familiar with valgrind to be able to
judge. It would depend upon what "valgrind.h" actually does.
If it causes packages to be statically linked against valgrind libs, it
would at least be legally "muddy terrain", to say the least.
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)
Do they only bundle valgrind.h or more of valgrind?
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.
OK, you seem to be saying "header only".
Such cases are not uncommon to find in "C++" packages ("Header-only
libs"), but are fairly rare for "C" (C lacks C++-"templates").
We (FPC) commonly treat them as a special case of both bundling and
copylibs.
If this use-case is technically useful, it probably would be useful to a
"Provides: bundled(valgrind.h) = <version>" to these packages, to make
them easier identifiable in future.
Should this use-case not be technically useful (E.g to shadowing
valgrind's API/ABI), then enforcing using the external package should be
mandatory.
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.
Sounds reasonable to me.
It also would seem reasonable to me to file a ticket to FPC, such that
FPC can try to examine this case.
Ralf
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
