Hi,
I'm the maintainer of NGINX package for Fedora/EPEL 7. The most commonly recommended way to install NGINX on CentOS 7 is via the EPEL 7 repository. However, for the last few days this has not been possible.
libunwind is now included in RHEL 7.2 (having previously been only in EPEL 7 repo). Unfortunately, the maintainer for the RHEL libunwind broke the upgrade path by using a Release (1.1-5) lower than the EPEL libunwind (1.1-10). To fix this, libunwind got immediately retired from EPEL 7:
https://bugzilla.redhat.com/show_bug.cgi?id=1288313
Unfortunately, that means libunwind cannot be installed at all on CentOS 7 unless you enable CR repository. NGINX depends on gperftools which depends on libunwind, so users cannot install NGINX:
https://bugzilla.redhat.com/show_bug.cgi?id=1289073
My plan was to *unretire* libunwind from EPEL, but to avoid breaking RHEL I had to wait for the RHEL maintainer to bump the Release of libunwind on RHEL. Sadly, maintainer said this won't happen until the next batch update on January 19th.
Another possibility is to remove gperftools support from NGINX, which would make NGINX installable again while waiting for the release of CentOS 7.2. However, I definitely can't take this approach as it would break NGINX for existing users who need the gperftools module and that would be even worse.
So, would it be possible to include the libunwind-1.1-5 package (from CentOS-CR) in CentOS-base before CentOS 7.2 is actually released? I'm very open to hear any other suggestions of how I might fix this, but I seem to be running out of options.
Kind regards, Jamie
On 12/09/2015 01:08 PM, Jamie Nguyen wrote:
Hi,
I'm the maintainer of NGINX package for Fedora/EPEL 7. The most commonly recommended way to install NGINX on CentOS 7 is via the EPEL 7 repository. However, for the last few days this has not been possible.
libunwind is now included in RHEL 7.2 (having previously been only in EPEL 7 repo). Unfortunately, the maintainer for the RHEL libunwind broke the upgrade path by using a Release (1.1-5) lower than the EPEL libunwind (1.1-10). To fix this, libunwind got immediately retired from EPEL 7:
https://bugzilla.redhat.com/show_bug.cgi?id=1288313
Unfortunately, that means libunwind cannot be installed at all on CentOS 7 unless you enable CR repository. NGINX depends on gperftools which depends on libunwind, so users cannot install NGINX:
https://bugzilla.redhat.com/show_bug.cgi?id=1289073
My plan was to *unretire* libunwind from EPEL, but to avoid breaking RHEL I had to wait for the RHEL maintainer to bump the Release of libunwind on RHEL. Sadly, maintainer said this won't happen until the next batch update on January 19th.
Another possibility is to remove gperftools support from NGINX, which would make NGINX installable again while waiting for the release of CentOS 7.2. However, I definitely can't take this approach as it would break NGINX for existing users who need the gperftools module and that would be even worse.
So, would it be possible to include the libunwind-1.1-5 package (from CentOS-CR) in CentOS-base before CentOS 7.2 is actually released? I'm very open to hear any other suggestions of how I might fix this, but I seem to be running out of options.
As you have already mentioned, all the users need to do is to enable the CR repository . Or wait until CentOS 7.2 will be released, which will happen "soon". And given that the CR repository contains exactly what will become CentOS 7.2 (thus behaving like any regular update), I do not see why wouldn't the NGINX users use it.
On 09/12/15 11:37, Manuel Wolfshant wrote:
As you have already mentioned, all the users need to do is to enable the CR repository . Or wait until CentOS 7.2 will be released, which will happen "soon". And given that the CR repository contains exactly what will become CentOS 7.2 (thus behaving like any regular update), I do not see why wouldn't the NGINX users use it.
I would argue that newcomers to RHEL/CentOS are very likely to have heard of EPEL from numerous guides on the Internet, but are unlikely to have heard of CR (or even know what CR stands for).
Also, if a newcomer happens to hear about CR and read the CR page [0], it doesn't exactly fill them with confidence (though I've never actually seen breakage on CR, this is what is advertised):
They are less comprehensively reviewed in the QA validation stage. Will likely have a few more build issues. Please also subscribe to the centos-cr-announce list.
Also, when installing nginx, you get this error message:
--> Finished Dependency Resolution Error: Package: gperftools-libs-2.4-5.el7.x86_64 (epel) Requires: libunwind.so.8()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
It's not obvious (to the newcomer) from this error message that the solution is to enable CR repository.
Kind regards, Jamie
[0]: From https://wiki.centos.org/AdditionalResources/Repositories/CR
On 12/09/2015 02:09 PM, Jamie Nguyen wrote:
On 09/12/15 11:37, Manuel Wolfshant wrote:
As you have already mentioned, all the users need to do is to enable the CR repository . Or wait until CentOS 7.2 will be released, which will happen "soon". And given that the CR repository contains exactly what will become CentOS 7.2 (thus behaving like any regular update), I do not see why wouldn't the NGINX users use it.
I would argue that newcomers to RHEL/CentOS are very likely to have heard of EPEL from numerous guides on the Internet, but are unlikely to have heard of CR (or even know what CR stands for).
1. the issue only affects CentOS users and it will only happen until CentOS 7.2 is released 2. Users and especially newcomers are expected to read the docs. In CentOS 7.2 the CR repo comes preinstalled but disabled.
Also, if a newcomer happens to hear about CR and read the CR page [0], it doesn't exactly fill them with confidence (though I've never actually seen breakage on CR, this is what is advertised):
They are less comprehensively reviewed in the QA validation stage. Will likely have a few more build issues. Please also subscribe to the centos-cr-announce list.
Right. So those with fear in mind should either purchase a RH subscription or wait until CentOS QA is done. Or ask for advice in one of the proper CentOS support channels.
Also, when installing nginx, you get this error message:
--> Finished Dependency Resolution Error: Package: gperftools-libs-2.4-5.el7.x86_64 (epel) Requires: libunwind.so.8()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
It's not obvious (to the newcomer) from this error message that the solution is to enable CR repository.
It is not obvious at all. But newcomers should read the docs rather that trying copy/pasting random pieces of advice from google
Kind regards, Jamie
None of your arguments changes the fact that the base repository for CentOS 7.1 ships exactly what RHEL shipped in its 7.1 release (modulo the packages which were modified/added/removed by CentOS at the time of release) and by definition this cannot change. The only thing that CentOS could potentially do NOW is to ship the newer libunwind in the 7.1/updates repository but given the potential breakage it might cause and that the release of 7.2 (which includes the new libunwind in the base repo) is "around the corner" I highly doubt that this is a good idea.
On 09/12/15 12:41, Manuel Wolfshant wrote:
- the issue only affects CentOS users and it will only happen until
CentOS 7.2 is released
Strangely, you're trying to reassure me that it only affects CentOS users, even though the very reason I'm posting here is *because* it affects CentOS users.
Again, strangely, you're trying to reassure me about the 7.2 release date, even though it's evident I'm trying to solve this problem without having to wait (otherwise I wouldn't have bothered posting here). Please note that I didn't come here for a release date and I don't expect to be given one and that's *totally* fine and expected! But "soon" and "around the corner" are vague time-frames that I don't consider helpful in this discussion.
Right. So those with fear in mind should either purchase a RH subscription or wait until CentOS QA is done. Or ask for advice in one of the proper CentOS support channels.
It is not obvious at all. But newcomers should read the docs rather that trying copy/pasting random pieces of advice from google
None of your arguments changes the fact that the base repository for CentOS 7.1 ships exactly what RHEL shipped in its 7.1 release (modulo the packages which were modified/added/removed by CentOS at the time of release) and by definition this cannot change. The only thing that CentOS could potentially do NOW is to ship the newer libunwind in the 7.1/updates repository but given the potential breakage it might cause and that the release of 7.2 (which includes the new libunwind in the base repo) is "around the corner" I highly doubt that this is a good idea.
If CentOS considers it unwise or undesirable to push libunwind to 7.1/updates then I will wait for 7.2. Users can of course "read the docs" and reach out in the appropriate support channels, but I'm just trying to do my duty as a packager and reduce any avoidable headaches that users might face. Perhaps I'm being overenthusiastic in that goal, but I'd rather be overenthusiastic than negligent (which probably all packagers are guilty of at one time or another) and at least I can say I tried my best.
Kind regards, Jamie
On 12/09/2015 07:38 AM, Jamie Nguyen wrote:
On 09/12/15 12:41, Manuel Wolfshant wrote:
- the issue only affects CentOS users and it will only happen until
CentOS 7.2 is released
Strangely, you're trying to reassure me that it only affects CentOS users, even though the very reason I'm posting here is *because* it affects CentOS users.
Again, strangely, you're trying to reassure me about the 7.2 release date, even though it's evident I'm trying to solve this problem without having to wait (otherwise I wouldn't have bothered posting here). Please note that I didn't come here for a release date and I don't expect to be given one and that's *totally* fine and expected! But "soon" and "around the corner" are vague time-frames that I don't consider helpful in this discussion.
Right. So those with fear in mind should either purchase a RH subscription or wait until CentOS QA is done. Or ask for advice in one of the proper CentOS support channels.
It is not obvious at all. But newcomers should read the docs rather that trying copy/pasting random pieces of advice from google
None of your arguments changes the fact that the base repository for CentOS 7.1 ships exactly what RHEL shipped in its 7.1 release (modulo the packages which were modified/added/removed by CentOS at the time of release) and by definition this cannot change. The only thing that CentOS could potentially do NOW is to ship the newer libunwind in the 7.1/updates repository but given the potential breakage it might cause and that the release of 7.2 (which includes the new libunwind in the base repo) is "around the corner" I highly doubt that this is a good idea.
If CentOS considers it unwise or undesirable to push libunwind to 7.1/updates then I will wait for 7.2. Users can of course "read the docs" and reach out in the appropriate support channels, but I'm just trying to do my duty as a packager and reduce any avoidable headaches that users might face. Perhaps I'm being overenthusiastic in that goal, but I'd rather be overenthusiastic than negligent (which probably all packagers are guilty of at one time or another) and at least I can say I tried my best.
CentOS doesn't consider it anything. EPEL is written for RHEL and they have published the stuff for 7.2 already.
CentOS Linux is run by 5 guys and a volunteer QA team. We have not finished the 7.2.1511 upgrade cycle yet.
CentOS does not have any control over what EPEL does.
When we get the release done, it will work. Until then you can use CR if you want.
Thanks, Johnny Hughes
On 12/09/2015 07:51 AM, Johnny Hughes wrote:
On 12/09/2015 07:38 AM, Jamie Nguyen wrote:
On 09/12/15 12:41, Manuel Wolfshant wrote:
- the issue only affects CentOS users and it will only happen until
CentOS 7.2 is released
Strangely, you're trying to reassure me that it only affects CentOS users, even though the very reason I'm posting here is *because* it affects CentOS users.
Again, strangely, you're trying to reassure me about the 7.2 release date, even though it's evident I'm trying to solve this problem without having to wait (otherwise I wouldn't have bothered posting here). Please note that I didn't come here for a release date and I don't expect to be given one and that's *totally* fine and expected! But "soon" and "around the corner" are vague time-frames that I don't consider helpful in this discussion.
Right. So those with fear in mind should either purchase a RH subscription or wait until CentOS QA is done. Or ask for advice in one of the proper CentOS support channels.
It is not obvious at all. But newcomers should read the docs rather that trying copy/pasting random pieces of advice from google
None of your arguments changes the fact that the base repository for CentOS 7.1 ships exactly what RHEL shipped in its 7.1 release (modulo the packages which were modified/added/removed by CentOS at the time of release) and by definition this cannot change. The only thing that CentOS could potentially do NOW is to ship the newer libunwind in the 7.1/updates repository but given the potential breakage it might cause and that the release of 7.2 (which includes the new libunwind in the base repo) is "around the corner" I highly doubt that this is a good idea.
If CentOS considers it unwise or undesirable to push libunwind to 7.1/updates then I will wait for 7.2. Users can of course "read the docs" and reach out in the appropriate support channels, but I'm just trying to do my duty as a packager and reduce any avoidable headaches that users might face. Perhaps I'm being overenthusiastic in that goal, but I'd rather be overenthusiastic than negligent (which probably all packagers are guilty of at one time or another) and at least I can say I tried my best.
CentOS doesn't consider it anything. EPEL is written for RHEL and they have published the stuff for 7.2 already.
CentOS Linux is run by 5 guys and a volunteer QA team. We have not finished the 7.2.1511 upgrade cycle yet.
CentOS does not have any control over what EPEL does.
When we get the release done, it will work. Until then you can use CR if you want.
And in case this has not been said before, libunwind was added to RHEL in 7,2, so will be part of the new release of CentOS Linux when we are done .. it was therefore removed from EPEL.
On 09/12/15 13:58, Johnny Hughes wrote:
CentOS doesn't consider it anything. EPEL is written for RHEL and they have published the stuff for 7.2 already.
CentOS Linux is run by 5 guys and a volunteer QA team. We have not finished the 7.2.1511 upgrade cycle yet.
Hi, I think you misunderstood what I was trying to say. I'm definitely not trying to rush CentOS developers into releasing 7.2. I was trying to see if libunwind could be included in the CentOS 7.1 repositories.
CentOS does not have any control over what EPEL does.
I don't expect or require CentOS to have any control over EPEL. (Perhaps you misunderstood and thought I thought I was asking about pushing libunwind to EPEL?)
When we get the release done, it will work. Until then you can use CR if you want.
And in case this has not been said before, libunwind was added to RHEL in 7,2, so will be part of the new release of CentOS Linux when we are done .. it was therefore removed from EPEL.
That's exactly what I said in my first email in this thread.
Kind regards, Jamie
On 12/09/2015 08:10 AM, Jamie Nguyen wrote:
On 09/12/15 13:58, Johnny Hughes wrote:
CentOS doesn't consider it anything. EPEL is written for RHEL and they have published the stuff for 7.2 already.
CentOS Linux is run by 5 guys and a volunteer QA team. We have not finished the 7.2.1511 upgrade cycle yet.
Hi, I think you misunderstood what I was trying to say. I'm definitely not trying to rush CentOS developers into releasing 7.2. I was trying to see if libunwind could be included in the CentOS 7.1 repositories.
CentOS does not have any control over what EPEL does.
I don't expect or require CentOS to have any control over EPEL. (Perhaps you misunderstood and thought I thought I was asking about pushing libunwind to EPEL?)
When we get the release done, it will work. Until then you can use CR if you want.
And in case this has not been said before, libunwind was added to RHEL in 7,2, so will be part of the new release of CentOS Linux when we are done .. it was therefore removed from EPEL.
That's exactly what I said in my first email in this thread.
Thanks Jamie,
Sorry for being short before. We are working flat out trying to get 7.2.1511 out the door.
As background. I am kind of hesitant to break the linunwind that we are going to release in the new CentOS tree while this bug is being sorted out that the EPEL version is newer than the RHEL 7.2 version here:
https://bugzilla.redhat.com/show_bug.cgi?id=1288313
I know you are on that bug as well.
My issue with putting the EPEL version in CentOS Extras is that then when we release 7.2.1511 it will be newer than the version in our OS tree until Red Hat does their epoch thing as discussed on the bug.
Obviously they don't want to use the new version if libunwind from EPEL, if that were going to he the course of action, I would do it. Since it is not, and they want the current version tehy have in RHEL 7.2, I would rather wait. Does this make sense?
We hope to have the actual 7.2.1511 tree syncing to the mirrors in a day or so. What we are currently working on is the impact of the new Security Profiles and getting our ISO package lists updated for that after we got it debranded. I think we are close on that, and we have solved numerous other issues and I don't see any blockers to release right now.
Of course, that is not a guarantee, something else might come up, but I think we are very close.
If it looks like we are going to delay past this weekend at least getting the tree's on te mirrors (because we find issues), then we can look at this issue again.
Thanks, Johnny Hughes
On 09/12/15 15:54, Johnny Hughes wrote:
As background. I am kind of hesitant to break the linunwind that we are going to release in the new CentOS tree while this bug is being sorted out that the EPEL version is newer than the RHEL 7.2 version here:
https://bugzilla.redhat.com/show_bug.cgi?id=1288313
I know you are on that bug as well.
My issue with putting the EPEL version in CentOS Extras is that then when we release 7.2.1511 it will be newer than the version in our OS tree until Red Hat does their epoch thing as discussed on the bug.
Obviously they don't want to use the new version if libunwind from EPEL, if that were going to he the course of action, I would do it. Since it is not, and they want the current version tehy have in RHEL 7.2, I would rather wait. Does this make sense?
We are actually in agreement already, as I wasn't suggesting for libunwind from EPEL to be included in CentOS Extras. Rather, I was suggesting that the libunwind from CentOS-CR be included in CentOS Extras. That way NGINX from EPEL can be installed and most importantly the upgrade paths for both RHEL and CentOS are kept intact.
(I do appreciate there is limited time and other more important priorities, such as the release of CentOS.)
Kind regards, Jamie
On 12/09/2015 10:21 AM, Jamie Nguyen wrote:
On 09/12/15 15:54, Johnny Hughes wrote:
As background. I am kind of hesitant to break the linunwind that we are going to release in the new CentOS tree while this bug is being sorted out that the EPEL version is newer than the RHEL 7.2 version here:
https://bugzilla.redhat.com/show_bug.cgi?id=1288313
I know you are on that bug as well.
My issue with putting the EPEL version in CentOS Extras is that then when we release 7.2.1511 it will be newer than the version in our OS tree until Red Hat does their epoch thing as discussed on the bug.
Obviously they don't want to use the new version if libunwind from EPEL, if that were going to he the course of action, I would do it. Since it is not, and they want the current version tehy have in RHEL 7.2, I would rather wait. Does this make sense?
We are actually in agreement already, as I wasn't suggesting for libunwind from EPEL to be included in CentOS Extras. Rather, I was suggesting that the libunwind from CentOS-CR be included in CentOS Extras. That way NGINX from EPEL can be installed and most importantly the upgrade paths for both RHEL and CentOS are kept intact.
(I do appreciate there is limited time and other more important priorities, such as the release of CentOS.)
OK, I did some testing and I put the 7.2 version in 7.1 CentOS extras and that seems OK. In 30 minutes or so, it should be on mirror.centos.org. Please test and see if that works in the interim.
Thanks, Johnny Hughes
On 09/12/15 17:28, Johnny Hughes wrote:
OK, I did some testing and I put the 7.2 version in 7.1 CentOS extras and that seems OK. In 30 minutes or so, it should be on mirror.centos.org. Please test and see if that works in the interim.
Amazing. Thanks so much!
I can confirm that libunwind is installable (and consequently NGINX) with the following in CentOS-Base.repo:
baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
Kind regards, Jamie
On Wed, Dec 9, 2015 at 11:20 AM, Jamie Nguyen j@jamielinux.com wrote:
On 09/12/15 17:28, Johnny Hughes wrote:
OK, I did some testing and I put the 7.2 version in 7.1 CentOS extras and that seems OK. In 30 minutes or so, it should be on mirror.centos.org. Please test and see if that works in the interim.
Amazing. Thanks so much!
I can confirm that libunwind is installable (and consequently NGINX) with the following in CentOS-Base.repo:
baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
Kind regards, Jamie
Thanks Jaime and Johnny, I think this is a good solution.
- Ken
On Wed, Dec 9, 2015 at 12:27 PM, Ken Dreyer kdreyer@redhat.com wrote:
On Wed, Dec 9, 2015 at 11:20 AM, Jamie Nguyen j@jamielinux.com wrote:
On 09/12/15 17:28, Johnny Hughes wrote:
OK, I did some testing and I put the 7.2 version in 7.1 CentOS extras and that seems OK. In 30 minutes or so, it should be on mirror.centos.org. Please test and see if that works in the interim.
Amazing. Thanks so much!
I can confirm that libunwind is installable (and consequently NGINX) with the following in CentOS-Base.repo:
baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
Kind regards, Jamie
Thanks Jaime and Johnny, I think this is a good solution.
(Whoops, I misspelled your name Jamie, my bad!)
- Ken
On 09/12/15 19:27, Ken Dreyer wrote:
On Wed, Dec 9, 2015 at 11:20 AM, Jamie Nguyen j@jamielinux.com wrote:
On 09/12/15 17:28, Johnny Hughes wrote:
OK, I did some testing and I put the 7.2 version in 7.1 CentOS extras and that seems OK. In 30 minutes or so, it should be on mirror.centos.org. Please test and see if that works in the interim.
Amazing. Thanks so much!
I can confirm that libunwind is installable (and consequently NGINX) with the following in CentOS-Base.repo:
baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
Kind regards, Jamie
Thanks Jaime and Johnny, I think this is a good solution.
This is a terrible solution. Its a kludge for the best way, and just highlights the dire need for EPEL to be better integrated into the CentOS side of things.
Regards,
On 9 December 2015 at 15:28, Karanbir Singh mail-lists@karan.org wrote:
On 09/12/15 19:27, Ken Dreyer wrote:
On Wed, Dec 9, 2015 at 11:20 AM, Jamie Nguyen j@jamielinux.com wrote:
On 09/12/15 17:28, Johnny Hughes wrote:
OK, I did some testing and I put the 7.2 version in 7.1 CentOS extras and that seems OK. In 30 minutes or so, it should be on mirror.centos.org. Please test and see if that works in the interim.
Amazing. Thanks so much!
I can confirm that libunwind is installable (and consequently NGINX) with the following in CentOS-Base.repo:
baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
Kind regards, Jamie
Thanks Jaime and Johnny, I think this is a good solution.
This is a terrible solution. Its a kludge for the best way, and just highlights the dire need for EPEL to be better integrated into the CentOS side of things.
I think that depends on what "better integrated" means.
Does it mean that it requires CR to be enabled? Does it mean that it doesn't build against RHEL but CentOS (and which channels in CentOS)? [In this case it wouldn't see the libunwind problem until 7.2.1512 was available but would mean that RHEL users would be stuck until that happened?] etc etc.
On 12/09/2015 02:28 PM, Karanbir Singh wrote:
This is a terrible solution. Its a kludge for the best way, and just highlights the dire need for EPEL to be better integrated into the CentOS side of things.
How should EPEL resolve the situation?
If they kept their own libunwind package, that would violate their policy against conflicting with packages in RHEL.
EPEL could have two branches, for RHEL and CentOS separately, and push packages to the CentOS repo when CentOS catches up with RHEL. That seems like a lot of work to cover a relatively rare problem.
I don't see another reasonable way they could resolve the situation, as long as CentOS and RHEL are on asynchronous release schedules.
It seems like CentOS might be able to partially resolve the problem by beginning work on their update releases when RHEL goes into beta, rather than waiting for general availability. I don't know if those packages are or could be available to CentOS during beta, though. There's some risk that RH would make changes that would invalidate some of the work done during beta, but I don't know how often that happens in practice. What are your thoughts?
On 9 December 2015 at 16:10, Gordon Messmer gordon.messmer@gmail.com wrote:
On 12/09/2015 02:28 PM, Karanbir Singh wrote:
This is a terrible solution. Its a kludge for the best way, and just highlights the dire need for EPEL to be better integrated into the CentOS side of things.
How should EPEL resolve the situation?
If they kept their own libunwind package, that would violate their policy against conflicting with packages in RHEL.
Well the issue sort of effects RHEL customers also... if they had installed EPEL libunwind but the RHEL version update gives them an incompatible one then they are stuck with a broken package(s)... until a rebuild of those packages occur. some sort of integration could allow for either the window of that being smaller or better found.
EPEL could have two branches, for RHEL and CentOS separately, and push packages to the CentOS repo when CentOS catches up with RHEL. That seems like a lot of work to cover a relatively rare problem.
I don't see another reasonable way they could resolve the situation, as long as CentOS and RHEL are on asynchronous release schedules.
It seems like CentOS might be able to partially resolve the problem by beginning work on their update releases when RHEL goes into beta, rather than waiting for general availability. I don't know if those packages are or could be available to CentOS during beta, though. There's some risk that RH would make changes that would invalidate some of the work done during beta, but I don't know how often that happens in practice. What are your thoughts?
The packages in beta are not generally available. CentOS is currently built from code dropshipped from Red Hat via a git repository and I don't believe the Beta code is available there. [My ignorance of this is mostly that I wouldn't know the git commands to find out :)]
On 12/10/2015 01:16 AM, Stephen John Smoogen wrote:
It seems like CentOS might be able to partially resolve the problem by beginning work on their update releases when RHEL goes into beta, rather than waiting for general availability. I don't know if those packages are or could be available to CentOS during beta, though. There's some risk that RH would make changes that would invalidate some of the work done during beta, but I don't know how often that happens in practice. What are your thoughts?
The packages in beta are not generally available. CentOS is currently built from code dropshipped from Red Hat via a git repository and I don't believe the Beta code is available there.
it is not.
On 09/12/15 22:28, Karanbir Singh wrote:
This is a terrible solution. Its a kludge for the best way, and just highlights the dire need for EPEL to be better integrated into the CentOS side of things.
Actually, I see this as a lack of communication between RHEL and EPEL, so this problem could have been avoided with better integration between RHEL and EPEL (not CentOS and EPEL, though of course that would be great too).
I don't think that the EPEL libunwind maintainer was aware that RHEL was intending to ship their own libunwind. RHEL libunwind-1.1-5 was committed in June in order to "beat" EPEL libunwind-1.1-3 (and the RHEL maintainer told me that their internal review process *does* include a check for EPEL upgrade path). However, later the EPEL maintainer built libunwind-1.1-10 and this is where the problems began.
If the EPEL maintainer had been aware of RHEL's libunwind package, he could have chosen "Release: 3%{?dist}.1" and "Release: 3%{?dist}.2" etc. for future builds on EPEL to avoid conflicting with RHEL/CentOS. EPEL wouldn't have needed to retire libunwind so quickly (ie, retire only after CentOS 7.2 is released), and we wouldn't have had this problem at all.
Kind regards, Jamie
On 10 decembrie 2015 09:47:00 EET, Jamie Nguyen j@jamielinux.com wrote:
On 09/12/15 22:28, Karanbir Singh wrote:
This is a terrible solution. Its a kludge for the best way, and just highlights the dire need for EPEL to be better integrated into the CentOS side of things.
Actually, I see this as a lack of communication between RHEL and EPEL, so this problem could have been avoided with better integration between RHEL and EPEL (not CentOS and EPEL, though of course that would be great too).
I don't think that the EPEL libunwind maintainer was aware that RHEL was intending to ship their own libunwind. RHEL libunwind-1.1-5 was committed in June in order to "beat" EPEL libunwind-1.1-3 (and the RHEL maintainer told me that their internal review process *does* include a check for EPEL upgrade path). However, later the EPEL maintainer built libunwind-1.1-10 and this is where the problems began.
If the EPEL maintainer had been aware of RHEL's libunwind package, he could have chosen "Release: 3%{?dist}.1" and "Release: 3%{?dist}.2" etc. for future builds on EPEL to avoid conflicting with RHEL/CentOS. EPEL wouldn't have needed to retire libunwind so quickly (ie, retire only after CentOS 7.2 is released), and we wouldn't have had this problem at all.
Kind regards, Jamie
You are perfectly right here on all points. Unfortunately RH , short of providing access to beta to the customers, never announces in advance what packages will overlap with EPEL
On 10/12/15 07:54, Manuel Wolfshant wrote:
You are perfectly right here on all points. Unfortunately RH , short of providing access to beta to the customers, never announces in advance what packages will overlap with EPEL
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. (I haven't yet figured out which one.)
Kind regards, Jamie
On Thu, Dec 10, 2015 at 8:34 AM, Jamie Nguyen j@jamielinux.com wrote:
On 10/12/15 07:54, Manuel Wolfshant wrote:
You are perfectly right here on all points. Unfortunately RH , short of providing access to beta to the customers, never announces in advance what packages will overlap with EPEL
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. (I haven't yet figured out which one.)
Kind regards, Jamie
By the way I filed this bug report about 2 weeks ago but it went unnoticed:
https://bugzilla.redhat.com/show_bug.cgi?id=1285902
Akemi
-
Akemi Yagi -
Gordon Messmer -
Jamie Nguyen -
Johnny Hughes -
Karanbir Singh -
Ken Dreyer -
Manuel Wolfshant -
Stephen John Smoogen