Finding all the source packages that include a copy of valgrind.h

[Ralf Corsepius]

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