On 06/21/2012 10:18 AM, Alec Leamas wrote:
I raised this issue on rpmfusion-devel. However, I think it's general
enough to seek advice also here on fedora-devel. since it's really about
how to understand the filtering guidelines.
Hi!
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 filtering page on the wiki is rather out of date as it pre-dates rpm
4.9 (F-15 onwards), which includes a native filtering mechanism and
doesn't require that the internal dependency generator be turned off,
and is therefore safe to use on packages containing binaries.
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?
Adding the following lines seems to achieve what you're looking for:
# Avoid provides/requires from private libraries
%global privlibs Complete
%global privlibs %{privlibs}|CompleteGui
%global privlibs %{privlibs}|Drawing
%global privlibs %{privlibs}|DrawingGui
%global privlibs %{privlibs}|Fem
%global privlibs %{privlibs}|FemGui
%global privlibs %{privlibs}|FreeCAD
%global privlibs %{privlibs}|FreeCADGui
%global privlibs %{privlibs}|Image
%global privlibs %{privlibs}|ImageGui
%global privlibs %{privlibs}|ImportGui
%global privlibs %{privlibs}|Inspection
%global privlibs %{privlibs}|InspectionGui
%global privlibs %{privlibs}|Mesh
%global privlibs %{privlibs}|MeshGui
%global privlibs %{privlibs}|MeshPart
%global privlibs %{privlibs}|MeshPartGui
%global privlibs %{privlibs}|Part
%global privlibs %{privlibs}|PartDesign
%global privlibs %{privlibs}|PartDesignGui
%global privlibs %{privlibs}|PartGui
%global privlibs %{privlibs}|Points
%global privlibs %{privlibs}|PointsGui
%global privlibs %{privlibs}|QtUnitGui
%global privlibs %{privlibs}|Raytracing
%global privlibs %{privlibs}|RaytracingGui
%global privlibs %{privlibs}|ReverseEngineering
%global privlibs %{privlibs}|ReverseEngineeringGui
%global privlibs %{privlibs}|Robot
%global privlibs %{privlibs}|RobotGui
%global privlibs %{privlibs}|Sketcher
%global privlibs %{privlibs}|SketcherGui
%global privlibs %{privlibs}|Start
%global privlibs %{privlibs}|StartGui
%global privlibs %{privlibs}|WebGui
%global privlibs %{privlibs}|libFreeCADApp
%global privlibs %{privlibs}|libFreeCADBase
%global privlibs %{privlibs}|libFreeCADGui
%global __provides_exclude ^(%{privlibs})\\.so
%global __requires_exclude ^(%{privlibs})\\.so
A more succinct approach (which I haven't tried) would be:
%global __provides_exclude_from ^%{_libdir}/freecad/lib/.*\\.so$
%global __requires_exclude_from ^%{_libdir}/freecad/lib/.*\\.so$
but that would also drop dependencies required *by* those private
libraries as well as the private libraries themselves, so I prefer the
more long-winded approach.
Paul.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
