Hi, I already answered this on rpmfusion-devel, but for completeness, here's my answer again: Alec Leamas wrote: > I'm reviewing a package 2300 which at a glance seems to need filtering: > it both Requires: and Provides: it's internal plugin libraries, many of > which with generic names likely to clash with other packages symbols. > > But when I look at the guidelines at > http://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering, > they seem to be contradictory: > - One one hand, a package "Must not export RPM dependency information > which is not global in nature..." e. g., plugins. > - On the other, a package which have binaries in PATH and/or system > libraries must not use filtering; this applies also to sub-packages. The reason for this restriction is because the way the filtering was implemented for versions of RPM older than 4.9 didn't support ELF coloring. RPM 4.9 now has native filtering support and the macros have become just wrappers around that. > 2300 is, at present, a package with binaries in $PATH (can't use > filtering) providing and requiring it's own plugins (must be filtered). > What should we do? > > Split into two independent packages built from same source? > > Thoughts? All currently supported versions of Fedora (but not RHEL) have RPM 4.9 or newer (even the almost-EOL F15 has 4.9.1), so the problem should be safe to ignore for packages only targeting Fedora and not EL. We should probably also get the guidelines updated to recommend using the RPM 4.9 filtering builtins directly rather than through those macros (and remove the obsolete restrictions on where filters may be used), but that's a matter for the FPC (Fedora Packaging Committee), so it needs to be brought to them. Kevin Kofler PS: https://fedorahosted.org/fpc/ticket/189 has been filed with the FPC since I wrote the above message. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
