Red Hat Bugzilla – Bug 871804
rhevm-dbscripts package is rhevm version independent
Last modified: 2012-12-04 15:03:27 EST
Description of problem:
dbscripts should be version locked (upgrade from 3.0)
[root@ps-ad2-set ~]# rpm -qR rhevm-dbscripts
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):
Steps to Reproduce:
1. yum update rhevm-dbscripts
nowadays is upgrade allowed and version is neglected
version should corresponds with rhevm
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.
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).