----- Original Message -----
From: "Yaniv Bronheim" <ybronhei(a)redhat.com>
To: "devel" <devel(a)ovirt.org>, "Nir Soffer"
<nsoffer(a)redhat.com>, "Francesco Romani" <fromani(a)redhat.com>
Cc: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
Sent: Sunday, August 28, 2016 2:17:56 PM
Subject: broken master: removal of release in spec requirements
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 see, and I'm ok with the revert.
I can take care, because who messed up should also clean up :)
That said, I still wonder if this applies only to development snapshots (I think yes,
customers shouldn't seen this), and, if so, how we could handle this differently
without a revert.
I think this change should be reverted and the solution should be in
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.
I still think this is not the best way :\
RedHat Engineering Virtualization R & D