Bug 1481470 - requires missing http-parser
requires missing http-parser
Status: CLOSED CANTFIX
Product: Fedora EPEL
Classification: Fedora
Component: nodejs (Show other bugs)
epel7
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Stephen Gallagher
Fedora Extras Quality Assurance
: Reopened
: 1481507 1487941 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-08-14 20:56 EDT by Brian J. Murrell
Modified: 2017-09-08 22:03 EDT (History)
24 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-23 14:31:09 EDT
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 Brian J. Murrell 2017-08-14 20:56:53 EDT
Description of problem:
nodejs Requires: http-parser >= 2.7.0 but there is no http-parser in EPEL

Version-Release number of selected component (if applicable):
nodejs-1:6.11.1-1.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.  yum install nodejs

Actual results:
Error: Package: 1:nodejs-6.11.1-1.el7.x86_64 (epel)
           Requires: libhttp_parser.so.2()(64bit)
Error: Package: 1:nodejs-6.11.1-1.el7.x86_64 (epel)
           Requires: http-parser >= 2.7.0

Expected results:
Should install without errors

Additional info:
Seems like http-parser used to be in EPEL but according to current mirrors it is not any more.
Comment 1 Brian J. Murrell 2017-08-14 21:42:22 EDT
I have seen https://src.fedoraproject.org/rpms/http-parser/c/38ad9debf904ba21277e7a569366cca5b7c2a26b?branch=epel7 BTW.

This just breaks anyone that is not on RHEL 7.4.

Is there any reason that http-parser cannot live in both RHEL 7.4 and EPEL, at least for some reasonable amount of "bridge" time until everyone can reasonably be expected to get updated to 7.4?
Comment 2 Brian J. Murrell 2017-08-15 07:18:07 EDT
So, clearly this is a duplicate of bug 1481008 however I disagree with the NOTABUG assessment there.

In the context of the EPEL project, I would maintain that this is a bug.

Not everyone is able to upgrade to RHEL 7.4 as immediately as it is released.  Some IT departments have processes that a new release has to go through before it can be deployed.

RHEL is also not the only consumer of EPEL.  Is it the intention of EPEL to ignore these non-RHEL distros?  TBH, I'm not entirely clear of the mandate of the EPEL project.  Is it intended to be a resource for the EL user-base at large or is it only focused on and concerned with RHEL specifically?
Comment 3 Stephen Gallagher 2017-08-15 07:55:16 EDT
(In reply to Brian J. Murrell from comment #1)
> I have seen
> https://src.fedoraproject.org/rpms/http-parser/c/
> 38ad9debf904ba21277e7a569366cca5b7c2a26b?branch=epel7 BTW.
> 
> This just breaks anyone that is not on RHEL 7.4.
> 
> Is there any reason that http-parser cannot live in both RHEL 7.4 and EPEL,
> at least for some reasonable amount of "bridge" time until everyone can
> reasonably be expected to get updated to 7.4?

Yes, unfortunately this particular package hit an edge-case that causes problems.

When RHEL 7.4 was released, the http-parser package that was included in RHEL ended up with a name-version-release (NVR) value that sorts as _older_ than the one provided by EPEL. What this means is that the version contained in the EPEL repository would be superseding the official one provided by RHEL, thus resulting in RHEL users being out of support for anything that depends on http-parser which includes both Node.js and the SSSD project. As these are critical parts of many setups, we need to avoid it.

Normally, the RHEL maintainers keep an eye on packages that are in EPEL and try to ensure that when adoing them to official RHEL repositories that they bump the release to make sure it replaces the EPEL package. Unfortunately in this particular case, the maintainer didn't realize this and we ended up in this situation.

There are no good solutions here, but we opted for dropping the package from EPEL so that we don't impact the support compliance of anyone using RHEL. I wish there was a way to address this that didn't negatively impact the CentOS users, but it *will* be fixed as soon as CentOS finishes its 7.4 update (which I honestly expected would have been available by now).

You're probably right that "NOTABUG" isn't the appropriate resolution. I'm going to mark this as CANTFIX instead.
Comment 4 Stephen Gallagher 2017-08-15 07:57:35 EDT
*** Bug 1481507 has been marked as a duplicate of this bug. ***
Comment 5 Brian J. Murrell 2017-08-15 08:09:45 EDT
(In reply to Stephen Gallagher from comment #3)
> the maintainer didn't realize this and we ended up in
> this situation.

Oh.  What an unfortunate situation then.  I understand what has gone wrong.  It's just a pity is all.
 
> There are no good solutions here,

Are the update-release processes for RHEL just too heavy to allow getting a RHEL 7.4 update out that bumps the NVR of http-parser to that above what is in EPEL in quick enough order?

> You're probably right that "NOTABUG" isn't the appropriate resolution. I'm
> going to mark this as CANTFIX instead.

Sounds good.  It may seem a trivial difference but those two resolution codes send very different messages.

Thanks for taking the time to explain the situation.
Comment 6 Brian J. Murrell 2017-08-15 08:12:43 EDT
I should also ask, is it still not worthwhile, even if it takes a while, to get an NVM bumped http-parser into RHEL 7.4 such that you can restore the EPEL one also, just for those folks that are stuck on EL < 7.4 (i.e. while it's regression tested by IT departments, etc.)?
Comment 7 Stephen Gallagher 2017-08-15 09:24:51 EDT
(In reply to Brian J. Murrell from comment #6)
> I should also ask, is it still not worthwhile, even if it takes a while, to
> get an NVM bumped http-parser into RHEL 7.4 such that you can restore the
> EPEL one also, just for those folks that are stuck on EL < 7.4 (i.e. while
> it's regression tested by IT departments, etc.)?

I have made that request into RHEL already. No decision on the issue (either way) has yet been made public.

It was suggested offline by Zuzanna that we could temporarily bundle http-parser in Node.js, which I wish I had thought of last week. At this point, I think it's unlikely that a Node.js update carrying the bundled copy would make it out of the epel-testing repository faster than just waiting for CentOS to release the http-parser package, but we can at least have it in testing as a temporary solution.
Comment 8 Fedora Update System 2017-08-15 12:49:47 EDT
nodejs-6.11.2-1.2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-1788cd6310
Comment 9 Michael Chapman 2017-08-17 00:04:08 EDT
Is this new nodejs-6.11.2-1.2.el7 package missing "Obsoletes: http-parser < $something" and "Provides: http-parser == $something" tags of some kind? How will people who currently have nodejs and http-parser installed as separate packages upgrade to this nodejs and not end up with file conflicts?
Comment 10 Stephen Gallagher 2017-08-17 08:22:36 EDT
(In reply to Michael Chapman from comment #9)
> Is this new nodejs-6.11.2-1.2.el7 package missing "Obsoletes: http-parser <
> $something" and "Provides: http-parser == $something" tags of some kind? How
> will people who currently have nodejs and http-parser installed as separate
> packages upgrade to this nodejs and not end up with file conflicts?

The temporary bundled version is statically compiled into the binary. It does not put libhttp_parser.so.* into /usr/lib[64], so it will coexist fine with the existing package.
Comment 11 Fedora Update System 2017-08-18 16:22:01 EDT
nodejs-6.11.2-1.2.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-1788cd6310
Comment 12 Marti Raudsepp 2017-08-21 09:27:19 EDT
Now nodejs and npm packages install from epel-testing, but fail when trying to install anything with npm. Tested with latest centos:7 Docker image:

yum install -y epel-release
yum install --enablerepo=epel-testing npm nodejs

[root@d4f742f16b96 /]# npm install bower
npm: relocation error: npm: symbol SSL_set_cert_cb, version libssl.so.10 not defined in file libssl.so.10 with link time reference
Comment 13 Marti Raudsepp 2017-08-22 06:36:14 EDT
Stephen Gallagher, if you break users like this for a significant span of time, then please provide some reasonable workaround, like uploading the original package to some trustworthy-looking URL and linking to it.

Looks like all the mirrors have already deleted the original http-parser-2.7.1-3.el7.x86_64.rpm :(

The CentOS 7.4 Continuous Release repository doesn't yet have any packages and a release is probably still several weeks away.

The only workaround I found is installing the http-parser package from Springdale Linux: http://springdale.math.ias.edu/data/puias/unsupported/7/x86_64/http-parser-2.7.1-3.sdl7.x86_64.rpm

For reference, the cause of this issue is bug 1477662.
Comment 14 Zuzana Svetlikova 2017-08-22 07:03:41 EDT
http-parser is still available from koji

yum install https://kojipkgs.fedoraproject.org//packages/http-parser/2.7.1/3.el7/x86_64/http-parser-2.7.1-3.el7.x86_64.rpm nodejs

That said, nodejs is installed from epel, not epel-testing and npm works fine.
Comment 15 Stephen Gallagher 2017-08-22 09:05:37 EDT
It looks like the OpenSSL 1.0.1 compatibility patch must have been broken in the latest testing release. Fortunately, RHEL 7.4 now provides 1.0.2, which will allow us to drop that patch. Unfortunately, that's yet another piece that doesn't really line up with CentOS...

I'm *not* going to be bundling OpenSSL from upstream because it's known to carry patent-encumbered codecs that are not allowed in Fedora/EPEL. So at this point, I think we have the following choices:

1) Downgrade to the last known version that we know the SSL patch worked on and carry bundled http-parser with it.

2) Try to fix the OpenSSL 1.0.1 patch (CCing someone who might be able to help)

3) Just move ahead with the version that works with RHEL 7.4 and deal with the fact that CentOS is running behind.

I'm inclined to go with 3) because it's the least error-prone and most supportable. People who have chosen to run CentOS know that the trade-off is that it will always trail RHEL. If they need packages faster than CentOS can provide, they can always go get a subscription.

I hate that this got broken, but between http-parser and OpenSSL, there's really not a lot of good options.
Comment 16 Fedora Update System 2017-08-23 14:28:07 EDT
nodejs-6.11.2-2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-1788cd6310
Comment 17 Stephen Gallagher 2017-08-23 14:31:09 EDT
OK, after investigation, this cannot be made to work without requiring OpenSSL 1.0.2 as well (at least, it cannot be made to work without spending more effort than makes sense since CentOS 7.4 is due any day now).

As a result, I've just pushed out a newer version of the package for EPEL 7 that just explicitly requires OpenSSL 1.0.2 at runtime. This *will not work* on CentOS until CentOS 7.4 is released.

I do apologize for the inconvenience, but I've exhausted the available workarounds.
Comment 18 Marti Raudsepp 2017-08-24 05:00:00 EDT
OK, thankfully CentOS 7.4 development is now far enough that the CR repository works. https://wiki.centos.org/AdditionalResources/Repositories/CR

Just run this:
    yum-config-manager --enable cr && yum update
Comment 19 Piotr Popieluch 2017-09-03 15:24:10 EDT
*** Bug 1487941 has been marked as a duplicate of this bug. ***
Comment 20 Rich Rauenzahn 2017-09-08 22:03:04 EDT
A slightly more conservative approach:

    yum-config-manager --enable cr
    yum install nodejs  # or update ...
    yum-config-manager --disable cr

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