Overlapping packages in CentOS 7 repo files from ovirt and mirror.centos.org
Hi all, The repo files for ovirt-4.0 seem to have overlapping packages from (el7 vs centos.el7 naming). resources.ovirt.org: ovirt-4.0 and mirror.centos.org/centos/7/virt/x86_64/ovirt-4.0/: centos-ovirt40-release for example vdsm-4.18.15.3-1.el7.centos.x86_64.rpm vs vdsm-4.18.15.3-1.el7.x86_64.rpm Which one should "win"? We need this for auditing purposes. Thanks. -- Richard Chan
On Thu, Dec 29, 2016 at 11:09 PM, Richard Chan <richard@treeboxsolutions.com
wrote:
Hi all,
The repo files for ovirt-4.0 seem to have overlapping packages from (el7 vs centos.el7 naming).
resources.ovirt.org: ovirt-4.0
and
mirror.centos.org/centos/7/virt/x86_64/ovirt-4.0/: centos-ovirt40-release
for example
vdsm-4.18.15.3-1.el7.centos.x86_64.rpm
vs
vdsm-4.18.15.3-1.el7.x86_64.rpm
Which one should "win"? We need this for auditing purposes.
Thanks.
Hi, when a new oVirt release is announced the oVirt project releases source code developed and tested during the release cycle. For convenience, the oVirt release engineering team builds rpms for Fedora, Red Hat Enterprise Linux and similar. oVirt is not a Linux distribution. Once oVirt release is available, the CentOS VIrtualization SIG packages the oVirt Virtualization Host related packages and make them available on CentOS mirrors. CentOS Linux is a Linux distribution. So, if you need auditing on CentOS only, you should rely on CentOS repositories and not enabling oVirt repositories on Virtualization Hosts. On the manager side, oVirt engine is not yet packaged by CentOS Virtualization SIG being it almost impossible to package without accessing maven central during the build which is not allowed by packaging policies. So, for the oVirt Engine host, you've no choice but use oVrit repositories or build rpms yourself. The fact you see overlapping versions in oVirt repo and CentOS Virtualization SIG repositories is due to the fact the two repositories are independent. You can use either the oVIrt one (built by oVirt release engineering) or the CentOS one (built by CentOS Virt SIG).
-- Richard Chan
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
"The fact you see overlapping versions in oVirt repo and CentOS Virtualization SIG repositories is due to the fact the two repositories are independent. You can use either the oVIrt one (built by oVirt release engineering) or the CentOS one (built by CentOS Virt SIG)." We are actually ok with using resources.ovirt.org packages but the CentOS VIrtualization SIG repo was enabled by ovirt-release40-4.0.5-2.noarch itself: /etc/yum.repos.d/ovirt-4.0-dependencies.repo: [centos-ovirt40-release] name=CentOS-7 - oVirt 4.0 baseurl=http://mirror.centos.org/centos/7/virt/$basearch/ovirt-4.0/ gpgcheck=0 enabled=1 This stanza does not use priority= or includepkgs= so is it deterministic that vdsm comes from resources.ovirt.org? 1. When I did a test run of "yum install vdsm": vdsm-* packages were pulled from ovirt-4.0 (yay!) but python-* safelease ioprocess openvswitch ovirt-imageio-* came from centos-ovirt40-release. 2. To be deterministic, i.e., force vdsm* from ovirt-4.0 insteaad of accidentally getting from CentOS SIG, I am considering (similar to the epel repo stanza) [centos-ovirt40-release] name=CentOS-7 - oVirt 4.0 baseurl=http://mirror.centos.org/centos/7/virt/$basearch/ovirt-4.0/ includepkgs=python-* safelease ioprocess openvswitch ovirt-imageio-* ## or exclude=vdsm* gpgcheck=0 enabled=1 What do you think about this tightening? Thanks.
Richard Chan
On Mon, Jan 2, 2017 at 3:41 PM, Richard Chan <richard@treeboxsolutions.com> wrote:
"The fact you see overlapping versions in oVirt repo and CentOS Virtualization SIG repositories is due to the fact the two repositories are independent. You can use either the oVIrt one (built by oVirt release engineering) or the CentOS one (built by CentOS Virt SIG)."
We are actually ok with using resources.ovirt.org packages but the CentOS VIrtualization SIG repo was enabled by ovirt-release40-4.0.5-2.noarch itself:
/etc/yum.repos.d/ovirt-4.0-dependencies.repo:
[centos-ovirt40-release] name=CentOS-7 - oVirt 4.0 baseurl=http://mirror.centos.org/centos/7/virt/$basearch/ovirt-4.0/ gpgcheck=0 enabled=1
This stanza does not use priority= or includepkgs= so is it deterministic that vdsm comes from resources.ovirt.org?
1. When I did a test run of "yum install vdsm": vdsm-* packages were pulled from ovirt-4.0 (yay!) but python-* safelease ioprocess openvswitch ovirt-imageio-* came from centos-ovirt40-release.
2. To be deterministic, i.e., force vdsm* from ovirt-4.0 insteaad of accidentally getting from CentOS SIG, I am considering (similar to the epel repo stanza)
[centos-ovirt40-release] name=CentOS-7 - oVirt 4.0 baseurl=http://mirror.centos.org/centos/7/virt/$basearch/ovirt-4.0/ includepkgs=python-* safelease ioprocess openvswitch ovirt-imageio-* ## or exclude=vdsm* gpgcheck=0 enabled=1
What do you think about this tightening? Thanks.
I think exclude vdsm* should be enough for your purpose.
Richard Chan
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
participants (2)
-
Richard Chan -
Sandro Bonazzola