I'll upload my full patches shortly, I have a mocked rebuild of all of the packages running now and need to verify that all worked as planned. The major issue with CentOS 6 is that these packages rely on the new /usr/lib/rpm/fileattrs/nodejs.attr dependency generation magic, support for which started in rpm 4.9.0. CentOS 6 ships with rpm 4.8.0 which doesn't understand this (Cent5.5 ships with 4.4.2.3), and therefore dependency information is totally missing for packages like npm which depend on nodejs module packages. 

The patch to the nodejs-* module specs was adding the following to the spec file:
%if 0%{?rhel}
# work around to allow us to find provides/requires with rpm < 4.9,
# which do not understand the magic in /usr/lib/rpm/nodejs.(req|prov)
%global __find_provides %{_rpmconfigdir}/nodejs.prov
%global __find_requires %{_rpmconfigdir}/nodejs.req 
%global _use_internal_dependency_generator 0
%endif

And adding the following below the existing Requires/BuildRequires:
%if 0%{?rhel}
# this will ONLY build with the macros, scripts, etc. from redhat-rpm-config
BuildRequires: redhat-rpm-config
BuildRequires: /usr/bin/python

# CentOS 6.x and lower use rpm < 4.9, so they don't understand the fancy new automatic
# dependency generation for scripting languages
Requires: /bin/sh /bin/bash /usr/bin/env
%endif

(In reply to comment #1)
> The patch to the nodejs-* module specs was adding the following to the spec
> file:
> %if 0%{?rhel}
> # work around to allow us to find provides/requires with rpm < 4.9,
> # which do not understand the magic in /usr/lib/rpm/nodejs.(req|prov)
> %global __find_provides %{_rpmconfigdir}/nodejs.prov
> %global __find_requires %{_rpmconfigdir}/nodejs.req 
> %global _use_internal_dependency_generator 0
> %endif

We'll definitely want to provide a %nodejs_gendeps macro or such to the nodejs package that takes care of this.

> And adding the following below the existing Requires/BuildRequires:
> %if 0%{?rhel}
> # this will ONLY build with the macros, scripts, etc. from redhat-rpm-config
> BuildRequires: redhat-rpm-config

This is part of the minimum build environment and should not be necessary:

$ sudo yum groupinfo buildsys-build
Loaded plugins: rhnplugin
Setting up Group Process

Group: Buildsystem building group
 Mandatory Packages:
   bash
   bzip2
   coreutils
   cpio
   diffutils
   epel-release
   findutils
   gawk
   gcc
   gcc-c++
   grep
   gzip
   info
   make
   patch
   redhat-rpm-config
   rpm-build
   sed
   shadow-utils
   tar
   unzip
   util-linux-ng
   which
   xz

> BuildRequires: /usr/bin/python

This is one of those that is pretty much guaranteed to be in the build environment, since Fedora/RHEL depends on Python so heavily, but technically isn't part of the minimum build environment and thus should have explicit BuildRequires anyway.  It should be in the specfile unconditionally.  (I believe there was a discussion about this type of stuff on the devel list recently but I can't find it.)

> # CentOS 6.x and lower use rpm < 4.9, so they don't understand the fancy new
> automatic
> # dependency generation for scripting languages
> Requires: /bin/sh /bin/bash /usr/bin/env

Actually it does, but you disable it to enable the Node.js generation.  Ideally we'll find a way to still call %{_rpmconfigdir}/find-requires from the node.js tooling so this isn't necessary.

> %endif

(In reply to comment #2)
> (In reply to comment #1)
> > The patch to the nodejs-* module specs was adding the following to the spec
> > file:
> > %if 0%{?rhel}
> > # work around to allow us to find provides/requires with rpm < 4.9,
> > # which do not understand the magic in /usr/lib/rpm/nodejs.(req|prov)
> > %global __find_provides %{_rpmconfigdir}/nodejs.prov
> > %global __find_requires %{_rpmconfigdir}/nodejs.req 
> > %global _use_internal_dependency_generator 0
> > %endif
> 
> We'll definitely want to provide a %nodejs_gendeps macro or such to the
> nodejs package that takes care of this.
Yeah, sounds logical. 
> 
> > And adding the following below the existing Requires/BuildRequires:
> > %if 0%{?rhel}
> > # this will ONLY build with the macros, scripts, etc. from redhat-rpm-config
> > BuildRequires: redhat-rpm-config
> 
> This is part of the minimum build environment and should not be necessary:
> 
> $ sudo yum groupinfo buildsys-build
> 
I haven't been able to find a source for that group for rhel5/cent5 anywhere. I'd be happy to be enlightened, but I spent quite a while looking around, and came up dry. I guess I could try creating it myself, but if it's not upstream anywhere, this is still needed (though I guess I could've locked that down to el5 only). Also, I've often found the "minimum build environment" to be confusing... I spent a while of my life downloading SRPMs and "rpmbuild"ing them and wondering why it didn't work, before I realized that I needed to do more to recreate the upstream build environment.
> 
> > BuildRequires: /usr/bin/python
> 
> This is one of those that is pretty much guaranteed to be in the build
> environment, since Fedora/RHEL depends on Python so heavily, but technically
> isn't part of the minimum build environment and thus should have explicit
> BuildRequires anyway.  It should be in the specfile unconditionally.  (I
> believe there was a discussion about this type of stuff on the devel list
> recently but I can't find it.)
>
Yeah. I added this because, while yum, etc. obviously depends on it, this package uses a python script to generate the provides/requires, and I wanted to make sure there couldn't be any issues with, say, (yes admittedly an edge case) someone trying a `rpmbuild`.
> 
> > # CentOS 6.x and lower use rpm < 4.9, so they don't understand the fancy new
> > automatic
> > # dependency generation for scripting languages
> > Requires: /bin/sh /bin/bash /usr/bin/env
> 
> Actually it does, but you disable it to enable the Node.js generation. 
> Ideally we'll find a way to still call %{_rpmconfigdir}/find-requires from
> the node.js tooling so this isn't necessary.
> 
> > %endif
The release notes for rpm 4.9.0 (http://www.rpm.org/wiki/Releases/4.9.0 under the Package Building section) say that this is a new feature. Either way, with the vanilla fc19 spec file (not overriding/disabling for the node.js generation) doesn't catch these unless I specify them by hand.

Maybe I'm missing something... if nodejs-devel (or nodejs) provides /usr/lib/rpm/nodejs.(prov|req), how do those provides/requires get added to nodejs and nodejs-devel themselves???

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > And adding the following below the existing Requires/BuildRequires:
> > > %if 0%{?rhel}
> > > # this will ONLY build with the macros, scripts, etc. from redhat-rpm-config
> > > BuildRequires: redhat-rpm-config
> > 
> > This is part of the minimum build environment and should not be necessary:
> > 
> > $ sudo yum groupinfo buildsys-build
> > 
> I haven't been able to find a source for that group for rhel5/cent5
> anywhere. I'd be happy to be enlightened, but I spent quite a while looking
> around, and came up dry. I guess I could try creating it myself, but if it's
> not upstream anywhere, this is still needed (though I guess I could've
> locked that down to el5 only). Also, I've often found the "minimum build
> environment" to be confusing... I spent a while of my life downloading SRPMs
> and "rpmbuild"ing them and wondering why it didn't work, before I realized
> that I needed to do more to recreate the upstream build environment.

Groups are defined in the comps.xml file shipped along with the repodata for every repo.  It looks like @buildsys-build is only provided by the EPEL comps.xml; It's not in the CentOS 6 comps.xml file that I can see.

If you're building packages from EPEL with EPEL disabled, you'll probably want to create a comps.xml in your private repo that includes most of the packages from the EPEL version.

> > > # CentOS 6.x and lower use rpm < 4.9, so they don't understand the fancy new
> > > automatic
> > > # dependency generation for scripting languages
> > > Requires: /bin/sh /bin/bash /usr/bin/env
> > 
> > Actually it does, but you disable it to enable the Node.js generation. 
> > Ideally we'll find a way to still call %{_rpmconfigdir}/find-requires from
> > the node.js tooling so this isn't necessary.
> > 
> > > %endif
> The release notes for rpm 4.9.0 (http://www.rpm.org/wiki/Releases/4.9.0
> under the Package Building section) say that this is a new feature. Either
> way, with the vanilla fc19 spec file (not overriding/disabling for the
> node.js generation) doesn't catch these unless I specify them by hand.

Yeah, what I meant was that we will probably want to call /usr/lib/rpm/find-requires from /usr/lib/rpm/nodejs.req so we don't have to add all these manually.

I've got a fully working build now. I've made a new set of commits at https://github.com/jantman/specfiles/tree/master/nodejs, so I have a single clean commit with all of the Koji specs to diff off of. It will probably be the weekend before I can do much more work on the spec files, as this is going to be personal-time-only until my employer needs another version bump.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

As of nodejs-0.10.4-1.el6, there exists a %nodejs_find_provides_and_requires macro that will set the %__find_(provides|requires) to use the Node.js dependency generator.  Additionally, that dependency generator now invokes the standard RPM dependency generator, so interpreter-based deps that were missing before (as well as the shared library ones in native modules) will be present.

I'd need to check the status of the various tracking bugs to be sure, but there are nodejs/npm packages now in EPEL6, so I'll assume that part of this is done.

Is EPEL5 still considered supported, or is it EOL? AFAIK from my investigation, these packages won't build correctly on centos5 due to node-gyp requiring a long chain of dependencies ending with a newer glibc. I have a co-worker trying to get a clean build on cent5.5 now, but it looks like the only solution might end up being removing node-gyp and any native module compilation on cent5.

Jason, I can't speak for the other folks working on Node.js in Fedora, but I have no plans whatsoever to attempt to get it working on EPEL5. It was difficult-enough to get it to work on EPEL6, because even there we have several packages that were too old. Some, like c-ares, I was able to create a parallel-installable copy of a newer version, but I can't touch OpenSSH in EPEL at all.

As it is, Node.js in EPEL 6 is technically still lacking in one specific area that I haven't had an opportunity to test exhaustively. It may not work with applications that require SPDY support because OpenSSH as shipped by RHEL 6 may not contain certain patches for SPDY support that were added in OpenSSH 1.0.1. (I can't find certainty about it in the changelogs for OpenSSH). Everything else appears to work though, so we went ahead with releasing it for EPEL 6 under the "Let's see if anyone actually has trouble and files a bug" plan. So far, things are going smoothly.

With all of that said, I'm going to strongly recommend that we abandon any plans for carrying an official build of Node.js on EPEL 5. All of its libraries are very old. You *may* be able to build an unofficial RPM from all of the bundled libraries directly from upstream, but we will never be able to carry that in EPEL.

I'm going to clone this bug at this point, since I think we've taken it as far as we can.

Sounds reasonable to me. If I manage to get my builds to succeed I'll post a link to my specs... I'm pretty sure for my company, at least at this point, we're going to try to build without node-gyp support, which should remove most of the dependencies (though this is obviously very far from anything "official" or which could be put in EPEL.

If you want to get in touch with me out of Bugzilla (tchollingsworth) I'd be happy to look into your node-gyp issue and see about maybe working out some sort of third-party repo (preferably with copr) for EL5.

I agree with Stephen that it's probably too much of a burden to support in EPEL 5 up to Fedora standards.