7:44 a.m.
Hi!
libunwind package is now part of RHEL 7.2. It got retired from EPEL7
three days ago (and incidentally the Release went backwards so upgrade
path is broken):
https://bugzilla.redhat.com/show_bug.cgi?id=1288313
Unfortunately, that leaves CentOS users in a bit of a pickle, as
libunwind is no longer installable (unless they enable CR repository or
wait X weeks until CentOS 7.2 is released).
NGINX depends on gperftools which depends on libunwind. So NGINX cannot
be installed on CentOS:
https://bugzilla.redhat.com/show_bug.cgi?id=1289073
I could rebuild NGINX without gperftools as a temporary solution, but
that would break NGINX for anyone using the google perftools module. If
I don't rebuild, then users can't even install NGINX in the first place.
It seems I'm in between a rock and a hard place. By the way, I don't
actually plan on rebuilding NGINX without gperftools as that would break
it for existing users, and new users can enable CR (but that assumes the
user can figure out the solution themselves).
So, in the general case of packages being retired from EPEL7 because
they have moved to RHEL, how do we avoid missing packages in the future?
Kind regards,
Jamie
8:59 a.m.
On Mon, Dec 07, 2015 at 01:44:30PM +0000, Jamie Nguyen wrote:
Hi!
libunwind package is now part of RHEL 7.2. It got retired from EPEL7
three days ago (and incidentally the Release went backwards so upgrade
path is broken):
https://bugzilla.redhat.com/show_bug.cgi?id=1288313
Unfortunately, that leaves CentOS users in a bit of a pickle, as
libunwind is no longer installable (unless they enable CR repository or
wait X weeks until CentOS 7.2 is released).
NGINX depends on gperftools which depends on libunwind. So NGINX cannot
be installed on CentOS:
https://bugzilla.redhat.com/show_bug.cgi?id=1289073
I could rebuild NGINX without gperftools as a temporary solution, but
that would break NGINX for anyone using the google perftools module. If
I don't rebuild, then users can't even install NGINX in the first place.
It seems I'm in between a rock and a hard place. By the way, I don't
actually plan on rebuilding NGINX without gperftools as that would break
it for existing users, and new users can enable CR (but that assumes the
user can figure out the solution themselves).
So, in the general case of packages being retired from EPEL7 because
they have moved to RHEL, how do we avoid missing packages in the future?
Could make a compat package in EPEL7 be an option?
This way you introduce back the version that was present without conflicting
with RHEL.
Pierre
9:17 a.m.
On 07/12/15 14:59, Pierre-Yves Chibon wrote:
On Mon, Dec 07, 2015 at 01:44:30PM +0000, Jamie Nguyen wrote:
> Hi!
>
> libunwind package is now part of RHEL 7.2. It got retired from EPEL7
> three days ago (and incidentally the Release went backwards so upgrade
> path is broken):
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1288313
>
> Unfortunately, that leaves CentOS users in a bit of a pickle, as
> libunwind is no longer installable (unless they enable CR repository or
> wait X weeks until CentOS 7.2 is released).
>
> NGINX depends on gperftools which depends on libunwind. So NGINX cannot
> be installed on CentOS:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1289073
>
> I could rebuild NGINX without gperftools as a temporary solution, but
> that would break NGINX for anyone using the google perftools module. If
> I don't rebuild, then users can't even install NGINX in the first place.
>
> It seems I'm in between a rock and a hard place. By the way, I don't
> actually plan on rebuilding NGINX without gperftools as that would break
> it for existing users, and new users can enable CR (but that assumes the
> user can figure out the solution themselves).
>
> So, in the general case of packages being retired from EPEL7 because
> they have moved to RHEL, how do we avoid missing packages in the future?
Could make a compat package in EPEL7 be an option?
This way you introduce back the version that was present without conflicting
with RHEL.
Could probably do something like what happens with packages that RHEL
doesn't ship for all architectures: the RHEL SRPM is cloned into EPEL,
the release field has "0." prepended to it to ensure that the RHEL
version is preferred where available, and the resulting package built
and shipped.
It wouldn't fix the upgrade path issue but should fix the dependencies.
Paul.
11:40 a.m.
FYI, this discussion might be better on the actual epel-devel list...
On Mon, 7 Dec 2015 15:17:54 +0000
Paul Howarth <paul(a)city-fan.org> wrote:
On 07/12/15 14:59, Pierre-Yves Chibon wrote:
...snip...
> Could make a compat package in EPEL7 be an option?
> This way you introduce back the version that was present without
> conflicting with RHEL.
Only if it's a actual different so version. Is it?
If not, why can't you use the version RHEL is shipping?
Could probably do something like what happens with packages that RHEL
doesn't ship for all architectures: the RHEL SRPM is cloned into
EPEL, the release field has "0." prepended to it to ensure that the
RHEL version is preferred where available, and the resulting package
built and shipped.
I don't think thats allowed. The package is in rhel, you cannot ship it
in EPEL just to be a different version.
kevin
2:58 a.m.
On 07/12/15 17:40, Kevin Fenzi wrote:
FYI, this discussion might be better on the actual epel-devel
list...
On Mon, 7 Dec 2015 15:17:54 +0000
Paul Howarth <paul(a)city-fan.org> wrote:
> On 07/12/15 14:59, Pierre-Yves Chibon wrote:
...snip...
>> Could make a compat package in EPEL7 be an option?
>> This way you introduce back the version that was present without
>> conflicting with RHEL.
Only if it's a actual different so version. Is it?
If not, why can't you use the version RHEL is shipping?
> Could probably do something like what happens with packages that RHEL
> doesn't ship for all architectures: the RHEL SRPM is cloned into
> EPEL, the release field has "0." prepended to it to ensure that the
> RHEL version is preferred where available, and the resulting package
> built and shipped.
I don't think thats allowed. The package is in rhel, you cannot ship it
in EPEL just to be a different version.
It's not a different version. It's an exact clone of the RHEL package
except with "0." in front of the release to make sure the RHEL package
"wins" where it is available. It is in fact the official EPEL
limited-arch package policy:
https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages
The problem this would fix is the broken deps in the window between RHEL
7.2 and CentoOS 7.2 releases, However, given the amount of time such a
package would take to get pushed to EPEL anyway, it's possible that
CentOS 7.2 would be released before the temporary fix, so it might not
be worth doing at all.
Paul.
10:07 a.m.
On 08/12/15 08:58, Paul Howarth wrote:
It's not a different version. It's an exact clone of the RHEL
package
except with "0." in front of the release to make sure the RHEL package
"wins" where it is available. It is in fact the official EPEL
limited-arch package policy:
https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages
The problem this would fix is the broken deps in the window between RHEL
7.2 and CentoOS 7.2 releases, However, given the amount of time such a
package would take to get pushed to EPEL anyway, it's possible that
CentOS 7.2 would be released before the temporary fix, so it might not
be worth doing at all.
Unfortunately, I don't think this is possible until the Red Hat
maintainer for libunwind bumps the Release.
RHEL = libunwind-1.1-5
EPEL = libunwind-1.1-10
If I introduce libunwind-1.1-0.5 then it doesn't mess up RHEL but it
*does* mess up EPEL (where the Release will go backwards from 10 to
0.5). And even if this was desirable, I doubt koji/bodhi would let
anyone do something like this (for good reason).
Kind regards,
Jamie
1:11 p.m.
On 08/12/15 16:07, Jamie Nguyen wrote:
Unfortunately, I don't think this is possible until the Red Hat
maintainer for libunwind bumps the Release.
RHEL = libunwind-1.1-5
EPEL = libunwind-1.1-10
If I introduce libunwind-1.1-0.5 then it doesn't mess up RHEL but it
*does* mess up EPEL (where the Release will go backwards from 10 to
0.5). And even if this was desirable, I doubt koji/bodhi would let
anyone do something like this (for good reason).
Bad news is that the RHEL maintainer got back to me and said that the
Release tag will be bumped in the next update push on January 19th. So I
gave up on my idea of "unretire libunwind for EPEL once Release is
bumped on RHEL".
Good news is that I opened a discussion on centos-devel [0] to ask if
the libunwind from CentOS-CR could be included in CentOS 7.1 repo, and
Johnny Hughes very kindly agreed to put libunwind in CentOS 7.1 Extras
repo. It's already on mirror.centos.org and once mirrors sync then NGINX
will be installable again (as will ceph which also broke).
Hurray!
Kind regards,
Jamie
[0]:
https://lists.centos.org/pipermail/centos-devel/2015-December/014101.html
11:30 a.m.
On 07/12/15 14:59, Pierre-Yves Chibon wrote:
> So, in the general case of packages being retired from EPEL7
because
> they have moved to RHEL, how do we avoid missing packages in the future?
Could make a compat package in EPEL7 be an option?
This way you introduce back the version that was present without conflicting
with RHEL.
The .so version is exactly the same, so it wouldn't really be a compat
package, but more of an exact duplicate. I'm not sure that's desirable?
Is there some kind of Red Hat policy for retiring EPEL packages that
have been brought to RHEL? If I understand correctly, there would have
been no need to retire libunwind so quickly if the upgrade path had been
kept intact (ie, the retirement could then at least have been delayed
until CentOS 7.2 was released).
I'd like to unretire libunwind for EPEL while waiting for CentOS 7.2,
but that would break RHEL. So I think what I need to do is wait until
the libunwind.rh maintainer has bumped the Release of libunwind.rh, then
request for libunwind.el7 to be unretired. But this process may not even
complete before CentOS 7.2 is released... thus making it rather pointless.
Kind regards,
Jamie
11:42 a.m.
On 07/12/15 15:33, Ken Dreyer wrote:
On Mon, Dec 7, 2015 at 6:44 AM, Jamie Nguyen <j(a)jamielinux.com>
wrote:
> So, in the general case of packages being retired from EPEL7 because
> they have moved to RHEL, how do we avoid missing packages in the future?
What is the issue with the CR CentOS repository?
It's not enabled by default. Newcomers to CentOS who want NGINX will
most likely follow some guide on the Internet that tells them to do this:
1. install CentOS
2. install EPEL
3. install NGINX
These newcomers have probably not heard of CR yet, and shouldn't need to
know about CR for NGINX to be installable. It's also not obvious when
installation fails that CR is the answer.
Kind regards,
Jamie
3058
days inactive
3060
days old
9 comments
5 participants
participants (5)
-
Jamie Nguyen -
Ken Dreyer -
Kevin Fenzi -
Paul Howarth -
Pierre-Yves Chibon