On Tue, 27 Oct 2009 10:51:14 +0000 (UTC), Fabio wrote:
Author: fabbione
Update of /cvs/pkgs/rpms/fence-agents/F-11 In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv15209
Modified Files: fence-agents.spec Log Message: Fix Requires: on libvirt/libvirt-client
+%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.
https://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires
Michael Schwendt wrote:
On Tue, 27 Oct 2009 10:51:14 +0000 (UTC), Fabio wrote:
Author: fabbione
Update of /cvs/pkgs/rpms/fence-agents/F-11 In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv15209
Modified Files: fence-agents.spec Log Message: Fix Requires: on libvirt/libvirt-client
+%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.
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.
Fabio
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.
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.
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
On Tue, 27 Oct 2009 12:37:28 +0100, Fabio wrote:
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.
You've misread that section. Most of it comments on file dependencies _outside_ (!) /etc and bin paths. Those are the ones you ought to avoid, as the depsolvers would need to download and parse additional metadata archives.
Michael Schwendt wrote:
On Tue, 27 Oct 2009 12:37:28 +0100, Fabio wrote:
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.
You've misread that section. Most of it comments on file dependencies _outside_ (!) /etc and bin paths. Those are the ones you ought to avoid, as the depsolvers would need to download and parse additional metadata archives.
Ok, thanks for the clarification.
Update spec files are on the way.
Fabio
-
Fabio M. Di Nitto -
Michael Schwendt