rpms/fence-agents/F-11 fence-agents.spec,1.13,1.14

Fabio M. Di Nitto fdinitto at redhat.com
Tue Oct 27 11:37:28 UTC 2009


Michael Schwendt wrote:
> On Tue, 27 Oct 2009 12:17:30 +0100, Fabio wrote:
> 
>>>> +%if 0%{?fedora} >= 12
>>>> +Requires: libvirt-client
>>>> +%else
>>>> +Requires: libvirt
>>>> +%endif
>>>> +
>>> What is this explicit dependency on a package name supposed to achieve?
>>> There is the automatic arch-specific dependency on the libvirt SONAME
>>> already, and it is tons better than a non-arch-specific and version-less
>>> dependency on a package name.
>> The dependency on the library is pulled in via fence_xvmd that might or
>> might be not build (depending on ./configure invocation).
>>
>> virsh used to be part of libvirt in any release before F12. It´s now
>> moved to libvirt-client.
>>
>> So while rpm resolver does the right thing for fence_xvmd and pulls in
>> the right soname Requires, it cannot detect the usage of virsh within
>> fence_virsh.
> 
> It's good practise to add a comment to the .spec file that explains
> this explicit dependency.

Ok, this is a no brainer. I´ll push the comment with the next series of
updates.

>  
>> If there are better ways to handle it, I am absolutely happy to change
>> the spec file but I don´t think it is correct either to break
>> fence_virsh because somebody is not building fence_xvmd* (that is going
>> to be deprecated upstream btw in not too long future).
>  
>> I also considered a specific file Requires: /usr/bin/virsh, but policy
>> suggests to avoid that for different reasons.
> 
> Really? What policy is that? Programs in bin paths are covered by the
> primary metadata. Such a dependency would be more accurate.

https://fedoraproject.org/wiki/Packaging/Guidelines#File_Dependencies

I understand that files in bin paths are already covered by primary
data, but the way it is formulated there, it sounds (to me) that there
is still extra processing involved from the different depsolver.

As I mentioned before, I am OK to change the spec file as long as
somebody else will not complain later that I should use the package (and
start playing ping-pong).

Fabio




More information about the fedora-devel-list mailing list