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(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org