Fwd: Filtering question

Kevin Kofler kevin.kofler at chello.at
Sat Jun 23 01:34:10 UTC 2012


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.

More information about the devel mailing list