Bug 1288313

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.

Can somebody at Red Hat please bump the release of libunwind package?

Email sent directly to mrezanin:

> 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

mrezanin 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

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.

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

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.

(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.

(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.

(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

Oops, if it wasn't clear I actually meant "4%{?dist}.1".

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

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.

Mirek, is there any code change in libunwind in this BZ?

Hi Fam,
there's no code change in libunwind due to this BZ.

Mirek,

the epoch number shouldn't be increased lightly.  I'd prefer to bump the release further to 11 or 20.

(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).

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.

As there were no other change in libunwind for 7.3, 7.2.z-stream version is in use.