RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1723396 - Z-Stream build not recognized as update because of %{dist} used by MBS
Summary: Z-Stream build not recognized as update because of %{dist} used by MBS
Keywords:
Status: CLOSED DUPLICATE of bug 1696354
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libssh2
Version: 8.0
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: rc
: 8.0
Assignee: Danilo de Paula
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-24 12:48 UTC by Josef Kubin
Modified: 2019-07-01 17:20 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-01 17:20:37 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Josef Kubin 2019-06-24 12:48:20 UTC 
Description of problem:

The libssh2 package has obviously wrong package numbering.

Newer libssh2 package was replaced by older package.

Newer package with several security fixes (considered older):
libssh2-1.8.0-7.module+el8.0.0+3075+09be6b65.1.x86_64.rpm

Older package (considered newer):
libssh2-1.8.0-7.module+el8+2833+c7d6d092.x86_64.rpm

How reproducible:
always
Comment 1 Kamil Dudka 2019-06-24 14:05:39 UTC 
Thank you for reporting the issue!  I can confirm the ordering by RPM:

% rpmdev-vercmp libssh2-1.8.0-7.module+el8.0.0+3075+09be6b65.1 libssh2-1.8.0-7.module+el8+2833+c7d6d092             
WARNING: hyphen in release1: 1.8.0-7.module+el8.0.0+3075+09be6b65.1
WARNING: hyphen in release2: 1.8.0-7.module+el8+2833+c7d6d092

rpmdev-vercmp <epoch1> <ver1> <release1> <epoch2> <ver2> <release2>
rpmdev-vercmp <EVR1> <EVR2>
rpmdev-vercmp # with no arguments, prompt

Exit status is 0 if the EVR's are equal, 11 if EVR1 is newer, and 12 if EVR2
is newer.  Other exit statuses indicate problems.

libssh2-1.8.0-7.module+el8.0.0+3075+09be6b65.1 < libssh2-1.8.0-7.module+el8+2833+c7d6d092
Comment 4 Danilo de Paula 2019-06-25 13:11:37 UTC 
Hi Kamil,

Modularity broke the regular update rules when introducing the zstream for rhel-8.0.0.
This is why every package is now built with the full 'el8.0.0' information.

We had this exactly same situation for a lot of other modular packages in RHEL (including some virt ones).
Sorry that I didn't notice that libssh2 was affected by this too.

Unfortunately, the official recommendation to fix this is to bump the release number. 
You could also bump the epoch, but bumping it means that you need to keep carrying that change for the rest of the package life.
Comment 7 Danilo de Paula 2019-06-26 13:41:47 UTC 
If we have a BZ, yes.
Comment 8 Josef Kubin 2019-06-27 12:47:44 UTC 
Origin of the bug (I forgot to mention it):
https://access.redhat.com/support/cases/internal/#/case/02397599
Comment 9 Danilo de Paula 2019-06-27 12:58:54 UTC 
There's is a related situation in bug 1712810:

Assume two packages:
RHEL-8.0.0: libguestfs-1.40.2-4.module+el8+3000+a8268fde
RHEL-8.1.0: libguestfs-1.40.2-4.module+el8.1.0+3225+a8268fde

Even tough they have the same content (both ships exactly same 1.40.2-4 version of libguestfs), rpm assumes that the first package has a higher version than the second.
This won't cause any real damage in that situation (it's not a real update), but kind of puts the module install out of sync.
Almost like the problem we have with the zstream release for libssh2 (although it causes a serios problem with libssh2) 

Here is what we have to do:

From my perspective, to be sure this is fixed once for all and we don't brake anything.
so we need five BZs:

1 - Bump all virt:rhel in rhel-8.0.0-z that are still using single 'el8' scheme (hint: all of them).

2 - If we do 1, then we also need to bump them in virt:rhel for RHEL-8.1.0 (to be sure they will be higher or, at least equal, in 8.0.0)

Same thing for RHEL-AV, but we need three BZs there:

3 - Bump all virt:8.0.0 package versions for RHEL-AV-8.0.0 (looks like every package uses el8 scheme)

4 - Bump all virt:8.0 packages RHEL-AV-8.0.1 

5 - Bump all virt:8.1 packages for RHEL-AV-8.1.0


Does it make sense Josh/Kamil? 
Sounds a bit harsh but it prevents this problem appearing again with other packages.
Comment 10 Josh Boyer 2019-06-27 14:00:03 UTC 
Yes, this makes sense.
Comment 11 Huzaifa S. Sidhpurwala 2019-06-28 08:02:35 UTC 
(In reply to Danilo Cesar de Paula from comment #9)
> There's is a related situation in bug 1712810:
> 
> Assume two packages:
> RHEL-8.0.0: libguestfs-1.40.2-4.module+el8+3000+a8268fde
> RHEL-8.1.0: libguestfs-1.40.2-4.module+el8.1.0+3225+a8268fde
> 
> Even tough they have the same content (both ships exactly same 1.40.2-4
> version of libguestfs), rpm assumes that the first package has a higher
> version than the second.
> This won't cause any real damage in that situation (it's not a real update),
> but kind of puts the module install out of sync.
> Almost like the problem we have with the zstream release for libssh2
> (although it causes a serios problem with libssh2) 
> 
> Here is what we have to do:
> 
> From my perspective, to be sure this is fixed once for all and we don't
> brake anything.
> so we need five BZs:
> 
> 1 - Bump all virt:rhel in rhel-8.0.0-z that are still using single 'el8'
> scheme (hint: all of them).
> 
> 2 - If we do 1, then we also need to bump them in virt:rhel for RHEL-8.1.0
> (to be sure they will be higher or, at least equal, in 8.0.0)
> 
> Same thing for RHEL-AV, but we need three BZs there:
> 
> 3 - Bump all virt:8.0.0 package versions for RHEL-AV-8.0.0 (looks like every
> package uses el8 scheme)
> 
> 4 - Bump all virt:8.0 packages RHEL-AV-8.0.1 
> 
> 5 - Bump all virt:8.1 packages for RHEL-AV-8.1.0
> 
> 
> Does it make sense Josh/Kamil? 
> Sounds a bit harsh but it prevents this problem appearing again with other
> packages.

Danilo,

Please let me know if you guys are planning to go ahead with the above solution.

It seems like this issue has caused a security regression for libssh2 as discussed in 
https://bugzilla.redhat.com/show_bug.cgi?id=1723396

We were thinking of doing a security errata, but if we are doing a mass nvr bump then it makes more sense, than fixing things one-off, since it may cause more problems later.
Comment 12 Kamil Dudka 2019-06-28 11:40:53 UTC 
(In reply to Danilo Cesar de Paula from comment #9)
> Does it make sense Josh/Kamil?

Yes, it makes sense to me.  So who will create/approve all the bugs?

Could someone from the virt team take care of the release bumps?

Honestly, I am still not fully confident with the libssh2 branching scheme and all the consequences of it.
Comment 13 Josh Boyer 2019-06-28 11:47:48 UTC 
(In reply to Kamil Dudka from comment #12)
> (In reply to Danilo Cesar de Paula from comment #9)
> > Does it make sense Josh/Kamil?
> 
> Yes, it makes sense to me.  So who will create/approve all the bugs?

There are already general purpose bugs that can be used.

8.1.0: https://bugzilla.redhat.com/show_bug.cgi?id=1695587
8.0.0z: https://bugzilla.redhat.com/show_bug.cgi?id=1696354

Commit against those.

> Could someone from the virt team take care of the release bumps?
> 
> Honestly, I am still not fully confident with the libssh2 branching scheme
> and all the consequences of it.
Comment 14 Danilo de Paula 2019-06-28 14:58:20 UTC 
I'll do the work, I did some yesterday.

I'm starting with 8.1.0 for RHEL and RHEL-AV. Why? Because if 8.0.1 or 8.0.0 gets released first and the change in 8.1.0 (for RHEL and AV) gets blocked by any reasons, the consequences will be worst.
I want to make sure that 8.1.0 (both rhel and av) is OK first, then 8.0.1 (for AV), then 8.0.0.z for RHEL and RHEL-AV.

I'm trying to script the change so it can be verified later, I will finish this today.
Comment 15 Kamil Dudka 2019-06-28 15:54:04 UTC 
Danilo, thank you for taking care of it!
Comment 16 Danilo de Paula 2019-07-01 17:20:37 UTC 
I'm closing this due to lack of flags and that this is fixed by bug 1696354

*** This bug has been marked as a duplicate of bug 1696354 ***
Note You need to log in before you can comment on or make changes to this bug.