Bug 871804 - rhevm-dbscripts package is rhevm version independent
rhevm-dbscripts package is rhevm version independent
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-setup (Show other bugs)
3.1.0
Unspecified Unspecified
urgent Severity high
: ---
: ---
Assigned To: Alex Lourie
Pavel Stehlik
integration
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-31 08:51 EDT by Pavel Stehlik
Modified: 2012-12-04 15:03 EST (History)
9 users (show)

See Also:
Fixed In Version: si24.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-04 15:03:27 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pavel Stehlik 2012-10-31 08:51:36 EDT
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:
Comment 1 Itamar Heim 2012-10-31 10:51:59 EDT
need to make sure dbscripts of 3.1 requires rhevm 3.1?
Comment 2 Alex Lourie 2012-10-31 11:34:05 EDT
In 3.1 rhevm-dbscripts is already a part of rpm lock list. Do we want to backport this?
Comment 3 Barak 2012-11-01 05:57:56 EDT
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 ?
Comment 4 Itamar Heim 2012-11-01 07:25:28 EDT
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.
Comment 5 Alex Lourie 2012-11-01 07:51:04 EDT
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.
Comment 6 Itamar Heim 2012-11-01 10:42:02 EDT
(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.
Comment 7 Alex Lourie 2012-11-02 08:23:20 EDT
Fix posted for review upstream: http://gerrit.ovirt.org/#/c/8991/
Comment 8 Alex Lourie 2012-11-03 17:58:37 EDT
fix posted for review downstream: https://gerrit.eng.lab.tlv.redhat.com/#/c/3063/
Comment 9 Ofer Schreiber 2012-11-04 04:50:05 EST
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).

Note You need to log in before you can comment on or make changes to this bug.