Bug 1390625

Summary: Improve %{dist} macro to contain exact RHOS version instead of just "ost" or add macro containing this version/
Product: Red Hat OpenStack Reporter: Peter Lemenkov <plemenko>
Component: relengAssignee: Greg Sterling <gsterlin>
Status: CLOSED WONTFIX QA Contact: Entitlement Bugs <entitlement-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 1.0 (Essex)CC: fdinitto, jeckersb, mburns, srevivo
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-12-21 16:17:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Peter Lemenkov 2016-11-01 14:34:33 UTC
Hello.
Currently every build for each RHOS release contains just a el7ost suffix. This means we cannot do the builds with the same version-release for different RHOS release versions. Consider adding RHOS' version as well. E.g. "%{dist}" should look like "ost9", "ost10", "ost11", and so on.

Comment 1 Peter Lemenkov 2016-11-01 15:02:37 UTC
less invasive approach - provide a macros which contains RHOS distribution version. In this case %{dist} remains intact (containing el7ost), and we will use new macro for that. Something like "%{?rhosdist}".

Comment 2 Mike Burns 2016-12-21 16:17:35 UTC
This has been discussed in the past and rejected.  We have many packages that don't change across releases or are updated for all releases concurrently (mariadb, rabbit, python dependencies, etc).  yum provides ways to determine which repo a package came from.

As a general rule, I think we should avoid the situation where we're doing multiple builds for multiple releases that have the same NVR except %dist.  If the contents between the versions is different, then we should reflect that with different numbering schemes.

For example:

rabbitmq-server-3.6.3-5.el7ost for osp 9
rabbitmq-server-3.6.3-6.el7ost for osp 10

If we must update osp 9 without going to -6 for OSP 10 (say we need 1 patch out of 2 backported), we should be doing 

rabbitmq-server-3.6.3-5.1.el7ost

instead of rabbitmq-server-3.6.3-6.el7ost9