Hi, In https://gerrit.ovirt.org/#/c/62672 we removed the release from vdsm* requirements. Although it sounds reasonable and quite safe, it was not. In development env it causes mixup of versions when upgrading. "yum install vdsm" will eventually cause this mixup as vdsm won't require the newer vdsm-python I think this change should be reverted and the solution should be in the build process. Newer release is equal to higher version, requirement should include the release number. so for example, 4.18.7-1 was shipped and for ppc we built 4.18.7-2 so 4.18.7-2 is newer. can't see how this can be different. e.g for the bug: ============================================================ ============================================================ ============================================================ =============================== Package Arch Version Repository Size ============================================================ ============================================================ ============================================================ =============================== Removing: vdsm x86_64 4.18.999-457.gitcde215c.el7.centos @ovirt-master-snapshot 2.7 M vdsm-api noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 325 k vdsm-cli noarch 4.18.999-457.gitcde215c.el7.centos @ovirt-master-snapshot 342 k vdsm-hook-vmfex-dev noarch 4.18.999-457.gitcde215c.el7.centos @ovirt-master-snapshot 21 k vdsm-jsonrpc noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 81 k vdsm-python noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 2.4 M vdsm-xmlrpc noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 109 k vdsm-yajsonrpc noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 95 k Problem. -- *Yaniv Bronhaim.* _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel

From: "Yaniv Bronheim" <ybronhei(a)redhat.com&gt; To: "devel" <devel(a)ovirt.org&gt;, "Nir Soffer" <nsoffer(a)redhat.com&gt;, "Francesco Romani" <fromani(a)redhat.com&gt; Cc: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com&gt; Sent: Sunday, August 28, 2016 2:17:56 PM Subject: broken master: removal of release in spec requirements Hi, In https://gerrit.ovirt.org/#/c/62672 we removed the release from vdsm* requirements. Although it sounds reasonable and quite safe, it was not. In development env it causes mixup of versions when upgrading. "yum install vdsm" will eventually cause this mixup as vdsm won't require the newer vdsm-python

I think this change should be reverted and the solution should be in the build process. Newer release is equal to higher version, requirement should include the release number. so for example, 4.18.7-1 was shipped and for ppc we built 4.18.7-2 so 4.18.7-2 is newer. can't see how this can be different.

From: "Nir Soffer" <nsoffer(a)redhat.com&gt; To: "Yaniv Bronheim" <ybronhei(a)redhat.com&gt; Cc: "devel" <devel(a)ovirt.org&gt;, "Francesco Romani" <fromani(a)redhat.com&gt;, "Yevgeny Zaspitsky" <yzaspits(a)redhat.com&gt; Sent: Monday, August 29, 2016 12:14:49 PM Subject: Re: broken master: removal of release in spec requirements On Sun, Aug 28, 2016 at 3:17 PM, Yaniv Bronheim <ybronhei(a)redhat.com&gt; wrote: > > Hi, > > In https://gerrit.ovirt.org/#/c/62672 we removed the release from vdsm* > requirements. Although it sounds reasonable and quite safe, it was not. > In development env it causes mixup of versions when upgrading. I think this change was unneeded, as vdsm builds for different architectures use the *same* release: name-major.minor.bugfix-release.offset.githash Unlike other packages using: name-major.minor.bugfix-release.timestamp.githash So I don't see why this patch was needed. Additionally, vdsm sub packages are tightly coupled, and using a package from different commit is *not* supported, as internal apis may always change. So we should revert this patch.