Hi Fedora noders!
If you're receiving this, you've done *something* related to Node at some point. (And there's a lot of you, which is why you're all Bcc'ed!) There's now a Node.js mailing list to make communicating easier: https://admin.fedoraproject.org/mailman/listinfo/nodejs
Please join us there if you're interested; this will be the last time I mass mail anybody. If you don't care about node anymore, feel free to skip the rest of this, otherwise read on..
In addition to the mailing list, I've also given node some wiki love. There's now an overview page you can point all your friends to: https://fedoraproject.org/wiki/Node.js
There's also a fancy SIG page. Add your name to it! https://fedoraproject.org/wiki/SIGs/Node.js
While I got them off to a start, they definitely could use some more love. Please edit away, it is a wiki after all!
Note that there's a link to a Packaging FAQ, but it currently redirects to the guidelines. I'm going to be putting in a guidelines update real soon now, taking into account all the changes thanks to your wonderful suggestions. Part of that will be moving some stuff out of the guidelines and into the FAQ, since FPC wants to get the guidelines back to the basics. [1] So that page won't stay a redirect long! If you have any suggestions in this area that we haven't already discussed previously, please e-mail the list. Otherwise, I'll send out the drafts there prior to sending them along to FPC to gather feedback.
Additionally, there's now a tracking bug for Node.js reviews [2]. Please add "nodejs-reviews" to the Blocks field of all future Node.js-related package reviews. npm2rpm will use it to skip packages that are already awaiting review. Speaking of npm2rpm, I hope to have that out for everyone next week, along with an additional script that checks npm for updates and updates packages. Sorry it's taken so long!
In case you missed it, Stephen Gallagher recently got Node.js working on EPEL 6. (Thanks, Stephen!) The only thing extra you need to do for EPEL is add %{?nodejs_find_provides_and_requires} to the top of your spec file. This forces the older RPM in RHEL6 to invoke the Node.js provides and requires generators, since it cannot be done automatically like it is in Fedora. (This will also find it's way into the EPEL guidelines in the aforementioned guidelines update.)
Finally, at this point in the Node.js 0.10.x release cycle, updates are being released roughly every week, as more people migrate to the new version and find all the bugs in it. Unfortunately, that means as soon as bodhi lets me push 0.10.4, 0.10.5 is out! Please test new versions, and visit bodhi and give them karma, so we're not pushing stuff with already fixed bugs stable two days after the next version is released. In about a month or so, releases should taper off and it won't be such a problem anymore.
Thanks for all of your awesome work!
-T.C.
[1] https://lists.fedoraproject.org/pipermail/packaging/2013-March/008971.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=956806
Quoting T.C. Hollingsworth (2013-04-25 20:07:21)
Hi Fedora noders!
If you're receiving this, you've done *something* related to Node at some point. (And there's a lot of you, which is why you're all Bcc'ed!) There's now a Node.js mailing list to make communicating easier: https://admin.fedoraproject.org/mailman/listinfo/nodejs
Heh, funnily enough just yesterday I was talking to thrcka about proposing some mailing list to simplify coordination and communication
Note that there's a link to a Packaging FAQ, but it currently redirects to the guidelines. I'm going to be putting in a guidelines update real soon now, taking into account all the changes thanks to your wonderful suggestions. Part of that will be moving some stuff out of the guidelines and into the FAQ, since FPC wants to get the guidelines back to the basics. [1]
Uhmm, that's was just my goal with Java guidelines since they have become bloated over time :-) In any case I believe it's a good idea to separate policy and common trips & tricks so +1 for this endeavor
Additionally, there's now a tracking bug for Node.js reviews [2]. Please add "nodejs-reviews" to the Blocks field of all future Node.js-related package reviews. npm2rpm will use it to skip packages that are already awaiting review. Speaking of npm2rpm, I hope to have that out for everyone next week, along with an additional script that checks npm for updates and updates packages. Sorry it's taken so long!
Great to hear, it will surely simplify and speed up common tasks. Automation is the key :-)
[snip]
Finally, at this point in the Node.js 0.10.x release cycle, updates are being released roughly every week, as more people migrate to the new version and find all the bugs in it. Unfortunately, that means as soon as bodhi lets me push 0.10.4, 0.10.5 is out! Please test new versions, and visit bodhi and give them karma, so we're not pushing stuff with already fixed bugs stable two days after the next version is released. In about a month or so, releases should taper off and it won't be such a problem anymore.
There's another thing which I mentioned to T.C., but I'll repeat it here in ML as well. It would be nice if we split up packaging of rpm macros and various helper scripts from nodejs package itself and create a separate project on fedorahosted just for those scripts/tools. It will simplify improvements to tooling and provide a common place where other distributions can perhaps share some code. We have something similar set up for Java packaging[1] for a while and it's been working great.
Last thing from me: in Java it became apparent only after a while...It might be good idea to create a separate "nodejs-local" or similarly named package used for RPM builds. This would pull in macros and all dependencies needed to build RPMs. Otherwise we'll possibly pollute user systems with rpm macros and additional dependencies even though they are not interested in packaging RPMs, just using node/npm.
[1] https://fedorahosted.org/javapackages/
Sorry, this went out to just Stanislav by accident. I'll recheck the list settings; I thought I configured it so Reply-To gets set to the list.
On Fri, Apr 26, 2013 at 2:34 AM, Stanislav Ochotnicky sochotnicky@redhat.com wrote:
Quoting T.C. Hollingsworth (2013-04-25 20:07:21)
Hi Fedora noders!
If you're receiving this, you've done *something* related to Node at some point. (And there's a lot of you, which is why you're all Bcc'ed!) There's now a Node.js mailing list to make communicating easier: https://admin.fedoraproject.org/mailman/listinfo/nodejs
Heh, funnily enough just yesterday I was talking to thrcka about proposing some mailing list to simplify coordination and communication
Get out of my brain! :-)
Note that there's a link to a Packaging FAQ, but it currently redirects to the guidelines. I'm going to be putting in a guidelines update real soon now, taking into account all the changes thanks to your wonderful suggestions. Part of that will be moving some stuff out of the guidelines and into the FAQ, since FPC wants to get the guidelines back to the basics. [1]
Uhmm, that's was just my goal with Java guidelines since they have become bloated over time :-) In any case I believe it's a good idea to separate policy and common trips & tricks so +1 for this endeavor
Well one member of FPC +1ed your idea at least, so it seemed worth it to go that route since I need to update the guidelines anyway. Yeah, this seems like a good idea. I wonder if npm2rpm and stuff like that should live in this package, or in it's own?
Last thing from me: in Java it became apparent only after a while...It might be good idea to create a separate "nodejs-local" or similarly named package used for RPM builds. This would pull in macros and all dependencies needed to build RPMs. Otherwise we'll possibly pollute user systems with rpm macros and additional dependencies even though they are not interested in packaging RPMs, just using node/npm.
I'm not sure this is necessary in node's case. The only thing RPM builds need that normal node use doesn't require is the RPM macros, which will end up in their own package eventually anyway.
-T.C.
Quoting T.C. Hollingsworth (2013-04-27 00:03:21)
Note that there's a link to a Packaging FAQ, but it currently redirects to the guidelines. I'm going to be putting in a guidelines update real soon now, taking into account all the changes thanks to your wonderful suggestions. Part of that will be moving some stuff out of the guidelines and into the FAQ, since FPC wants to get the guidelines back to the basics. [1]
Uhmm, that's was just my goal with Java guidelines since they have become bloated over time :-) In any case I believe it's a good idea to separate policy and common trips & tricks so +1 for this endeavor
Well one member of FPC +1ed your idea at least, so it seemed worth it to go that route since I need to update the guidelines anyway. Yeah, this seems like a good idea. I wonder if npm2rpm and stuff like that should live in this package, or in it's own?
Advantage of having single project is that you won't have to approve commit access several times :-) In Java we create single source tarball, but then spec file splits this into several smaller binary RPMs.
I guess it depends on how much code sharing you envision could happen there.
Last thing from me: in Java it became apparent only after a while...It might be good idea to create a separate "nodejs-local" or similarly named package used for RPM builds. This would pull in macros and all dependencies needed to build RPMs. Otherwise we'll possibly pollute user systems with rpm macros and additional dependencies even though they are not interested in packaging RPMs, just using node/npm.
I'm not sure this is necessary in node's case. The only thing RPM builds need that normal node use doesn't require is the RPM macros, which will end up in their own package eventually anyway.
Right, in Java those macros eventually started using Python/Perl and pulled in a few more dependencies. Plus RPM builds in Maven differ quite a lot dependency-wise from non-RPM so situation is indeed different. Something to keep in mind for the future in case something changes.
On Mon, Apr 29, 2013 at 12:02 AM, Stanislav Ochotnicky sochotnicky@redhat.com wrote:
Quoting T.C. Hollingsworth (2013-04-27 00:03:21)
Yeah, this seems like a good idea. I wonder if npm2rpm and stuff like that should live in this package, or in it's own?
Advantage of having single project is that you won't have to approve commit access several times :-) In Java we create single source tarball, but then spec file splits this into several smaller binary RPMs.
True. We'd definitely want to split the binary RPMs if we did this because npm2rpm will be much more dep heavy (it needs npm itself as well as a templating library).
I guess it depends on how much code sharing you envision could happen there.
None really. The current version uses the requires generator for nodejs to write BuildRequires based on package.json devDependencies, but I'm going to rip that out because the specific versioned dependencies that results in are really overkill for BuildRequires in Fedora packages.
I'm not sure this is necessary in node's case. The only thing RPM builds need that normal node use doesn't require is the RPM macros, which will end up in their own package eventually anyway.
Right, in Java those macros eventually started using Python/Perl and pulled in a few more dependencies. Plus RPM builds in Maven differ quite a lot dependency-wise from non-RPM so situation is indeed different. Something to keep in mind for the future in case something changes.
Well we use Python, but I purposely stuck to the standard library (well actually there wasn't really any reason not to ;-) and there isn't a practical Fedora installation without a Python interpreter thanks to yum and others, so I don't think that's a big deal.
Anyway, I'm going to go ahead and file a ticket for a nodejs-packaging fedorahosted project to get the ball rolling on this.
-T.C.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/02/2013 01:40 AM, T.C. Hollingsworth wrote:
On Mon, Apr 29, 2013 at 12:02 AM, Stanislav Ochotnicky sochotnicky@redhat.com wrote:
Quoting T.C. Hollingsworth (2013-04-27 00:03:21)
Yeah, this seems like a good idea. I wonder if npm2rpm and stuff like that should live in this package, or in it's own?
Advantage of having single project is that you won't have to approve commit access several times :-) In Java we create single source tarball, but then spec file splits this into several smaller binary RPMs.
True. We'd definitely want to split the binary RPMs if we did this because npm2rpm will be much more dep heavy (it needs npm itself as well as a templating library).
Please remember to consider the bootstrapping problem in the event of future mass-rebuilds. If the nodejs package starts build-depending on the npm package, that's a circular dependency that becomes very difficult to maintain. (I've seen how they have to do it in GCC, and it's not pretty).
I'd suggest that we might want to pull out the macro and npm2rpm stuff as a separate SRPM, mainly just to avoid this problem. So I'm all for the 'nodejs-packaging' project to be all-encompassing here.
On Thu, May 2, 2013 at 4:50 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On 05/02/2013 01:40 AM, T.C. Hollingsworth wrote:
On Mon, Apr 29, 2013 at 12:02 AM, Stanislav Ochotnicky sochotnicky@redhat.com wrote:
Quoting T.C. Hollingsworth (2013-04-27 00:03:21)
Yeah, this seems like a good idea. I wonder if npm2rpm and stuff like that should live in this package, or in it's own?
Advantage of having single project is that you won't have to approve commit access several times :-) In Java we create single source tarball, but then spec file splits this into several smaller binary RPMs.
True. We'd definitely want to split the binary RPMs if we did this because npm2rpm will be much more dep heavy (it needs npm itself as well as a templating library).
Please remember to consider the bootstrapping problem in the event of future mass-rebuilds. If the nodejs package starts build-depending on the npm package, that's a circular dependency that becomes very difficult to maintain. (I've seen how they have to do it in GCC, and it's not pretty).
I'm just talking about Requires: npm. We definitely wouldn't need BuildRequires on it (the only way that would ever be possible is for %check, but there's no network in koji so we couldn't use it for any tests there anyway). So, this shouldn't be a problem?
I'd suggest that we might want to pull out the macro and npm2rpm stuff as a separate SRPM, mainly just to avoid this problem. So I'm all for the 'nodejs-packaging' project to be all-encompassing here.
-T.C.
On Fri, May 3, 2013 at 6:53 AM, T.C. Hollingsworth tchollingsworth@gmail.com wrote:
Please remember to consider the bootstrapping problem in the event of future mass-rebuilds. If the nodejs package starts build-depending on the npm package, that's a circular dependency that becomes very difficult to maintain. (I've seen how they have to do it in GCC, and it's not pretty).
I'm just talking about Requires: npm. We definitely wouldn't need BuildRequires on it (the only way that would ever be possible is for %check, but there's no network in koji so we couldn't use it for any tests there anyway). So, this shouldn't be a problem?
Actually, come to think of it, there's still a nasty dep loop if npm2rpm and nodejs-packaging share SRPMs regardless of whether its build-time or runtime. It don't think it's realistically a problem for Fedora secondary arches since they just import noarch binary RPMs from primary wholesale, but better to avoid it anyway.
I'll get a nodejs-packaging package up for review soonish, so we can hopefully migrate to it when 0.10.6 comes out (which ought not to be for a little while; I see no interesting commits on the v0.10 branch since 0.10.5).
-T.C.
On 25/04/13 19:07, T.C. Hollingsworth wrote:
Hi Fedora noders!
<snip>
Great stuff, congrats everyone! Things are coming along nicely :)
I just spotted nodejs-tap on bodhi (thanks T.C.!). That means we now have mocha, expresso, should, vows, jasmine-node and tap in Fedora, which means most modules should be able to have their %check section enabled.
I plan to post a few more test-suite related packages for review at some point to increase our %check coverage even more (eg, nodeunit +deps, superagent, supertest etc), but of course anyone can feel free to beat me to it ;)
Kind regards,
On Fri, Apr 26, 2013 at 1:46 PM, Jamie Nguyen j@jamielinux.com wrote:
Great stuff, congrats everyone! Things are coming along nicely :)
I just spotted nodejs-tap on bodhi (thanks T.C.!). That means we now have mocha, expresso, should, vows, jasmine-node and tap in Fedora, which means most modules should be able to have their %check section enabled.
Sorry, I meant to mention that in that e-mail as well. I'll be enabling %check in the npm stack and rebuilding in Rawhide soon.
I plan to post a few more test-suite related packages for review at some point to increase our %check coverage even more (eg, nodeunit +deps, superagent, supertest etc), but of course anyone can feel free to beat me to it ;)
Awesome! A couple npm dependencies use nodeunit, so this will be very helpful.
-T.C.
nodejs@lists.fedoraproject.org
-
Jamie Nguyen -
Stanislav Ochotnicky -
Stephen Gallagher -
T.C. Hollingsworth