Bug 1473088 - http-parser missing as a dependency
Summary: http-parser missing as a dependency
Keywords:
Status: CLOSED DUPLICATE of bug 1457763
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: nodejs
Version: epel7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: NodeJS Packaging SIG
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-20 01:37 UTC by prasun.gera
Modified: 2017-07-24 10:22 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-24 10:22:33 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description prasun.gera 2017-07-20 01:37:58 UTC
Description of problem:
Installing npm has some dependency issues on RHEL 7. One one system, it pulled in nodejs010-http-parser and nodejs010-runtime from my RH SCL channel. This eventually fails to find the library with the following error: "node: error while loading shared libraries: libhttp_parser.so.2: cannot open shared object file: No such file or directory" because the libraries are installed under /opt/rh as a part of the SCL package that it pulls in. Instead, it should have pulled in the http-parser package from EPEL. This has also been documented on this blog: https://medium.com/@genebean/node-js-centos7-and-libhttp-parser-so-2-abb725e1aae8. On a different system, it worked fine, and seems to have got the right dependency. I'm not sure what triggers it to pull in the SCL package.

Version-Release number of selected component (if applicable):
npm-3.10.10-1.6.10.3.1.el7.x86_64

How reproducible: Not sure


Steps to Reproduce:
1. sudo yum install npm

Actual results:
node: error while loading shared libraries: libhttp_parser.so.2: cannot open shared object file: No such file or directory

Expected results:
No Error

Additional info:

Comment 1 Piotr Popieluch 2017-07-20 13:03:39 UTC
I think this bug should be filed against node in scl, not node in epel. I don't know where SCL bugs are tracked.

Comment 2 Piotr Popieluch 2017-07-20 13:11:48 UTC
Ah, I think I misread. You don't want to use the SCL npm? Then yum erase it, disable the scl repo in /etc/yum.repos.d, verify EPEL repo is enabled and SCL disabled (yum repolist), and yum install it again.

Comment 3 prasun.gera 2017-07-20 20:01:17 UTC
npm is still installed from epel. It just fails to find the correct dependencies. i.e., If scl and epel are enabled, and you call yum install npm, you get something that doesn't work. If epel's npm needs epel's http-parser, it should be packaged that way.

Comment 4 Piotr Popieluch 2017-07-21 16:17:29 UTC
I think the issue is that nodejs010-http-parser.x86_64 provides a generic so library instead of the scl specific one. This seems to be fixed/improved in nodejs4 scl.

see:

$ dnf repoquery --provides rh-nodejs4-http-parser.x86_64
libhttp_parser.so.rh-nodejs4-2.7.0()(64bit)

vs:

$ dnf repoquery --provides nodejs010-http-parser.x86_64
libhttp_parser.so.2()(64bit)


As epel-npm (or actually nodejs) requires libhttp_parser.so.2 and the scl http-parser package claims to provide that I think this should be filed against nodejs-010-http-parser.


@zsvetlik: Could you comment on this as you know way more about scl than me?

Comment 5 Zuzana Svetlikova 2017-07-24 10:21:55 UTC
Yes, it is a bug in nodejs010-http-parser, but won't be fixed since nodejs010 SCL is EOL.

Did you try installing nodejs from epel-testing?

Comment 6 Zuzana Svetlikova 2017-07-24 10:22:33 UTC

*** This bug has been marked as a duplicate of bug 1457763 ***


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