On 05/08/2012 04:40 PM, Eric Blake wrote:
On 05/08/2012 04:30 PM, Eric Blake wrote:
On 05/08/2012 10:04 AM, Osier Yang wrote:
As libnuma's API is used to set memory policy. --- libvirt.spec.in | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in index 95d8af4..f7764e8 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -457,8 +457,12 @@ BuildRequires: gawk BuildRequires: scrub
%if %{with_numad} +%if 0%{?fedora} >= 17 +BuildRequires: numactl-devel +%else BuildRequires: numad %endif +%endif
ACK.
Actually, I may have spoken too soon. See https://bugzilla.redhat.com/show_bug.cgi?id=812874.
I think we have two needs - when configuring, we need to know the location of the numad executable; and when linking, we need the numactl-devel libraries. Based on which packages provide those, we may need multiple BuildRequires. I'm still investigating what F16 vs. F17 provides.
NACK. Both F16 and F17 provide /usr/bin/numad in the numad package; I think the real dependency here is that you are stating that now, if we hard-code the use of numad, we are also requiring numactl-devel to be present. libvirt.spec.in already has a dependency on numactl-devel; what is missing is a configure check that errors out if you say --with-numactl=no --with-numad=yes. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org