Nodejs, Epel, SCL

Home » CentOS » Nodejs, Epel, SCL
CentOS 14 Comments

Hello,

​With SCL and epel repositories enabled, some dependencies for the package name ‘nodejs’ get satisfied with libs from SCL which are placed in paths that are not part of my user’s environment. Is there a method to make sure that nodeJS from epel dependencies are only satisfied from epel?

For example, the http parser dependency gets satisfied by nodejs010-http-parser-2.0-5.20121128gitcd01361.el6.CentOS.alt.x86_6

http-parser-2.0-4.20121128gitcd01361.el6.x86_64 : HTTP request/response parser for C
Repo : epel Matched from:
Filename : /usr/lib64/libhttp_parser.so.2
Other : libhttp_parser.so.2()(64bit)
Filename : /usr/lib64/libhttp_parser.so.2.0

http-parser-2.0-4.20121128gitcd01361.el6.i686 : HTTP request/response parser for C
Repo : epel Matched from:
Other : libhttp_parser.so.2
Filename : /usr/lib/libhttp_parser.so.2
Filename : /usr/lib/libhttp_parser.so.2.0

nodejs010-http-parser-2.0-5.20121128gitcd01361.el6.CentOS.alt.x86_64 : HTTP
request/response parser for C
Repo : scl Matched from:
Filename : /opt/rh/nodejs010/root/usr/lib64/libhttp_parser.so.2
Filename : /opt/rh/nodejs010/root/usr/lib64/libhttp_parser.so.2.0
Other : libhttp_parser.so.2()(64bit)

14 thoughts on - Nodejs, Epel, SCL

  • EPEL is self-reliant. Nothing in EPEL will depend on another other than Base/Updates. You need to check which repo you’re installing the package from, and be careful with the package name itself. There shouldn’t be duplicate names.

    In your example, the nodejs package is coming from SCL, so you would need to use the scl tools to enable that utility (which then appropriately updates your user’s environment)

    For example, ‘scl enable nodejs010 bash’ would give you a bash shell with the appropriate environment for using the nodejs from SCL.


    Jim Perrin The CentOS Project | http://www.CentOS.org twitter: @BitIntegrity | GPG Key: FA09AD77

  • Is yum supposed to track the dependencies separately? That is, if an EPEL package requires some other package (expected with the stock paths), can an SCL package fulfill that dependency even though it will be installed in a location that won’t work?

  • That can happen with the SCL repo … in cases where you are getting something you don’t want from SCL, exclude it via the CentOS-SCL.repo file in /etc/yum.repo.d/

    A line that says:

    exclude=nodejs0*

    should take care of that problem.

    If you are not using any SCLs, then you can disable the repo … IF you want to use both nodejs’s and EPEL’s does not work with the RHEL nodejs too, then they need to fix it as you should be able to install and use both.

  • SCL’s require that you properly configure them to work with the system
    … you CAN likely use that version IF you modify the environment for the program in question. Or you can use the EPEL version and exclude nodejs010 from the SCL’s .repo file in /etc/yum.repo.d/

    SCL’s are not automatically set up, as they are designed to only be used when properly configured and should live alongside other older packages. As such, they require added knowledge and administrative overhead, much like multiple 3rd party repos can … but they also provide lots of added capabilities.

  • That can happen with the SCL repo … in cases where you are getting something you don’t want from SCL, exclude it via the CentOS-SCL.repo file in /etc/yum.repo.d/

    A line that says:

    exclude=nodejs0*

    should take care of that problem.

    If you are not using any SCLs, then you can disable the repo … IF you want to use both nodejs’s and EPEL’s does not work with the RHEL nodejs too, then they need to fix it as you should be able to install and use both.

  • That seems pretty dangerous if the packages replace standard or EPEL
    libraries/components. I’d have expected them to have some sort of namespace concept for dependencies to keep the sets of packages completely independent. That is, I thought being independent was the point. Shouldn’t you be able to have multiple versions installed?

  • I consider this a bug, as the SCL’s should be self-contained. We’d need to see if this occurs upstream as well, and then file a bug there if so.

  • There’s really a bigger issue of how EPEL is supposed to fit in the world of ‘other’ repositories. What should happen when CentOSplus/extras has a same-named package? Other 3rd parties?

  • Then you have to figure it out … it happens. Many different repos have packages with the same name. If the repos don’t play nicely with each other, well then that is their fault. Garbage in / Garbage out.

  • The typical scenario is that EPEL doesn’t initially have a package so you have to get it from some other repository. Then EPEL adds it, but with different build/configuration options so every time the updates leapfrog your system breaks. Is this really not a solvable problem? Should we just expect EPEL to wantonly clobber anything, including CentOSplus/extras?