packaging-committee

#455 Policy for embedding private copies of valgrind.h
Closed: Fixed Opened by mjw.

Closed: Fixed
Reopen Issue

Dear Fedora Packaging Committee,

Recently valgrind 3.10.0 got released with a bug fix to valgrind.h for ppc32 and addition of two new supported architectures (aarch64 and ppc64le). Since several packages embed a private copy of valgrind.h, it has been a bit of a pain to determine which packages need to be updated/rebuild to take advantage of the bug fix and enhancements.

I created a tracking bug for packages that embed a private copy of valgrind.h (and other valgrind tool specific client request headers, memcheck.h, callgrind.h, etc.):
https://bugzilla.redhat.com/show_bug.cgi?id=1141461

Could there be a specific policy how to handle this case? Should these packages remove their private copy and add BuildRequires: valgrind-devel or should they update their copy and add a something like Provides: bundled(valgrind.h)

Some more background is in this fedora-devel thread:
https://lists.fedoraproject.org/pipermail/devel/2014-September/thread.html#202368

Thanks,

Mark

We looked at this in todays meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2014-09-25/fpc.2014-09-25-16.02.txt):

  • 455 Policy for embedding private copies of valgrind.h (geppetto,


    16:36:17)
  • ACTION: No packages should be bundling valgrind.h, FPC approves
    bundling requests (exactly so things like this don't happen) and
    hasn't approved any for valgrind.h. (geppetto, 16:39:18)
  • ACTION: Open BZs against the packages. If bundling is
    requested/approved, then the packages should have "Provides:
    bundled(valgrind.h)" (geppetto, 16:41:11)

...as it says, feel free to open BZs for the packages that are broken ... and they can in turn open FPC tickets to bundle if they need to continue to do so.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.