Bug 1288313 - libunwind in RHEL 7.2 has a smaller release than the last libunwind package in EPEL-7
libunwind in RHEL 7.2 has a smaller release than the last libunwind package i...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libunwind (Show other bugs)
7.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: 7.3
Assigned To: Miroslav Rezanina
Virtualization Bugs
: Rebase, ZStream
Depends On:
Blocks: 1289073 1289950
  Show dependency treegraph
 
Reported: 2015-12-03 22:19 EST by Anssi Johansson
Modified: 2016-11-09 09:21 EST (History)
16 users (show)

See Also:
Fixed In Version: libunwind-1.1-6.el7
Doc Type: Bug Fix
Doc Text:
Because of incorrect release numbering of the libunwind packages, updating libunwind sometimes failed due to a version conflict. With this update, the epoch number of libunwind downloaded from the Red Hat Enterprise Linux repository has been increased to make sure it is always considered a more recent version than libunwind from the Extra Packages repository. As a result, version conflicts are avoided, and the described failure no longer occurs.
Story Points: ---
Clone Of:
: 1289950 (view as bug list)
Environment:
Last Closed: 2016-11-09 09:21:35 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 Anssi Johansson 2015-12-03 22:19:39 EST
Description of problem:
RHEL 7.2 now includes libunwind, which means libunwind would need to be retired from EPEL 7.

Version-Release number of selected component (if applicable):
RHEL: libunwind-1.1-5.el7
EPEL: libunwind-1.1-10.el7 (yes, its release number is higher in EPEL)

Expected results:
EPEL packages should not conflict with packages in RHEL.
Comment 1 Tom "spot" Callaway 2015-12-04 10:30:54 EST
libunwind has been retired from EPEL-7. The RHEL maintainer should have checked EPEL to ensure a clean upgrade path, but since they didn't, they need to bump the release above 10 for the next available update. Reassigning this bug accordingly.
Comment 2 Jamie Nguyen 2015-12-09 03:58:17 EST
Can somebody at Red Hat please bump the release of libunwind package?
Comment 3 Jamie Nguyen 2015-12-09 04:10:12 EST
Email sent directly to mrezanin@redhat.com:

> Hi,
> 
> Please bump the release of libunwind package to 1.1-11 on RHEL7:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1288313
> 
> You introduced libunwind into RHEL without checking the upgrade path
> from EPEL (Release went backwards from 1.1-10 to 1.1-5). This conflict
> meant that libunwind had to be retired from EPEL immediately.
> 
> Unfortunately, this means NGINX cannot be installed on CentOS 7.
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1289073
> 
> I plan to unretire libunwind on EPEL while waiting for CentOS 7.2 to be
> released, but I cannot do this until you bump the Release of libunwind
> on RHEL.
> 
> Kind regards,
> Jamie
Comment 5 Jamie Nguyen 2015-12-09 05:27:13 EST
mrezanin@redhat.com kindly replied via email. Unfortunately, the situation is not so good. With unknown release date for CentOS 7.2, I may have to think of another way to fix this :(

> Hi Jamie,
> unfortunately this miss December release so fix will be released
> for RHEL on January 19th.
> 
> I'm not sure how to release it sooner for CentOS.
> 
> Mirek
Comment 6 Miroslav Rezanina 2015-12-09 05:38:33 EST
This issue will be fixed by raising epoch value. This allow fixing problem without version change. However, fix for RHEL 7.2 will be released with next batch update on January 19th.
Comment 7 Jamie Nguyen 2015-12-09 06:11:18 EST
I posted a message to centos-devel mailing list. Perhaps they can include libunwind package from CentOS-CR in CentOS-Base before CentOS 7.2 is released.

https://lists.centos.org/pipermail/centos-devel/2015-December/014101.html
Comment 9 Milan Bouchet-Valat 2015-12-09 09:39:18 EST
This very fast retirement also broke Copr builds, which can't find libunwind-devel on RHEL7 (I suppose because they haven't been updated to 7.2 yet). It would be nice to find a smoother solution in the future.
Comment 10 Jamie Nguyen 2015-12-09 10:21:47 EST
(In reply to Milan Bouchet-Valat from comment #9)
> This very fast retirement also broke Copr builds, which can't find
> libunwind-devel on RHEL7 (I suppose because they haven't been updated to 7.2
> yet). It would be nice to find a smoother solution in the future.

I think the solution is for the RHEL internal package review process to include a step that says "please check upgrade path from EPEL if package was previously in EPEL". Perhaps such a step already exists, but I'm that not familiar with how Red Hat does things internally.
Comment 11 Miroslav Rezanina 2015-12-09 10:35:06 EST
(In reply to Jamie Nguyen from comment #10)
> (In reply to Milan Bouchet-Valat from comment #9)
> > This very fast retirement also broke Copr builds, which can't find
> > libunwind-devel on RHEL7 (I suppose because they haven't been updated to 7.2
> > yet). It would be nice to find a smoother solution in the future.
> 
> I think the solution is for the RHEL internal package review process to
> include a step that says "please check upgrade path from EPEL if package was
> previously in EPEL". Perhaps such a step already exists, but I'm that not
> familiar with how Red Hat does things internally.

This step is present. Unfortunately, check was done before the EPEL version was increased so we did not bump the version number enough.
Comment 12 Jamie Nguyen 2015-12-09 10:50:56 EST
(In reply to Miroslav Rezanina from comment #11)
> This step is present. Unfortunately, check was done before the EPEL version
> was increased so we did not bump the version number enough.

So the check was done at least 5 months ago [0]. Of course, it can be unavoidable that the EPEL package needs to be rebuilt.

Is there a step that says "please communicate with EPEL package maintainer if package was previously in EPEL, so that EPEL maintainer can avoid increasing Release above what is in RHEL"?

So, for example, the EPEL libunwind maintainer could have chosen to use Release tag of "5%{?dist}.1" (but that of course assumes the EPEL maintainer has been told).

[0]: http://koji.fedoraproject.org/koji/buildinfo?buildID=667970
Comment 13 Jamie Nguyen 2015-12-09 10:52:01 EST
Oops, if it wasn't clear I actually meant "4%{?dist}.1".
Comment 14 Jamie Nguyen 2015-12-09 13:56:58 EST
I opened a discussion on centos-devel [0] and after some initial misunderstandings, Johnny Hughes very kindly agreed to put the CentOS 7.2 version of libunwind in CentOS 7.1 Extras repository.

libunwind-1.1-5 is now on mirror.centos.org [1] and will eventually find its way to other mirrors. This should resolve the problem.

[0]: https://lists.centos.org/pipermail/centos-devel/2015-December/014101.html
[1]: http://mirror.centos.org/centos/7/extras/x86_64/Packages/libunwind-1.1-5.el7.x86_64.rpm
Comment 15 Jamie Nguyen 2015-12-10 11:37:55 EST
After speaking with someone from RH, it turns out (thankfully) that RH does have a sensible policy here. The RHEL maintainer *must* contact the EPEL maintainer during the process of introducing a package to RHEL.

So either the RHEL libunwind maintainer didn't communicate as per the policy, or he did and the EPEL libunwind maintainer didn't do the right thing.

Either way, this is a problem that was avoidable. Hopefully some lessons have been learnt.
Comment 16 Fam Zheng 2015-12-15 02:37:48 EST
Mirek, is there any code change in libunwind in this BZ?
Comment 17 Miroslav Rezanina 2015-12-15 08:46:20 EST
Hi Fam,
there's no code change in libunwind due to this BZ.
Comment 18 Paolo Bonzini 2015-12-16 17:27:57 EST
Mirek,

the epoch number shouldn't be increased lightly.  I'd prefer to bump the release further to 11 or 20.
Comment 19 Jamie Nguyen 2015-12-17 02:03:13 EST
(In reply to Paolo Bonzini from comment #18)
> Mirek,
> 
> the epoch number shouldn't be increased lightly.  I'd prefer to bump the
> release further to 11 or 20.

1) I agree, there was no need to set an epoch. Fedora Packaging Guidelines advise to use it only "as a last resort" and should be "should be avoided wherever possible". I assume the RH Packaging Guidelines are similar.

2) There's no need to bump the release to more than 11. RH policy states that the maintainer *must* contact the EPEL maintainer when introducing a package to RHEL (though I assume this step was forgotten). If contacted and informed, the EPEL maintainer can then use a Release tag of "10%{?dist}.1" or "10%{?dist}.2" for future updates (and that would have avoided this entire mess).
Comment 20 Miroslav Rezanina 2016-05-05 09:31:43 EDT
I disagree in this case. We really start new life cycle of package in RHEL so it is new epoch. I discuss this solution with rel-eng and have it approved. We used this solution for 7.2.z so we shouldn't use different solution for 7.3.
Comment 21 Miroslav Rezanina 2016-11-09 09:21:35 EST
As there were no other change in libunwind for 7.3, 7.2.z-stream version is in use.

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