Description of problem: dbscripts should be version locked (upgrade from 3.0) [root@ps-ad2-set ~]# rpm -qR rhevm-dbscripts /bin/bash /bin/sh rhevm rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 Version-Release number of selected component (if applicable): si22.1 How reproducible: 100% Steps to Reproduce: 1. yum update rhevm-dbscripts 2. 3. Actual results: nowadays is upgrade allowed and version is neglected Expected results: version should corresponds with rhevm Additional info:
need to make sure dbscripts of 3.1 requires rhevm 3.1?
In 3.1 rhevm-dbscripts is already a part of rpm lock list. Do we want to backport this?
This is actually not a bug. It was meant initially to enable installation of a db independently. I would close this BZ per comment #2 above. Itamar ?
1. but we version locked it in another bug. 2. the current problem is a 3.0 customer will get the dbscripts package of 3.1 via yum update. we need the 3.1 dbscripts package to require rhevm-3.1 to not be deployed on 3.0 environments (which would blow up for them if they try to recover their system with them via backup/createdb/restore/etc.) 3. if we want to allow deploying this rpm on separate machines, you can conflict with <=3.1 instead of requiring it.
To provide any solution to 3.0 we would have to backport dbscripts rpm locking to the 3.0 (and deliver it in a Z stream). Is that what's requested? Otherwise, the issue is not relevant for 3.1 -> forward installations.
(In reply to comment #5) > To provide any solution to 3.0 we would have to backport dbscripts rpm > locking to the 3.0 (and deliver it in a Z stream). this will not solve the issue, since a 3.0 customer will get by then the 3.1 rpm. > > Is that what's requested? Otherwise, the issue is not relevant for 3.1 -> > forward installations. the issue is relevant to prevent a 3.0 customer from getting the 3.1 version of the rpm.
Fix posted for review upstream: http://gerrit.ovirt.org/#/c/8991/
fix posted for review downstream: https://gerrit.eng.lab.tlv.redhat.com/#/c/3063/
The problem I see with this fix: Assume we have a customer with 3.0 dbscripts package. this package is not locked. now, we release 3.1, and 3.1 dbscripts is available via yum. if the new package is requries rhevm >= 3.1 , we will have a big problem, as we will break his you dependency tree, since a regular `yum update` command will try to upgrade dbscripts, but he won't be able to find rhevm>= 3.1 (since it's locked).