I would also like to see nodejs updated and have been working on it a bit. I'm kind of amazed that anyone would have to justify upgrading an ancient release because obviously it has to been done at some point. Sooner rather than later I say. My reasons are performance and newer APIs and docs:
* Newer V8 has performance optimizations that are useful for workloads I have. * Various newer APIs would also be useful such as timing and cluster module and others. * Better debugging support for native extension loading issues. * The node.js homepage shows docs for the stable 0.8.x release. It's kind of tricky to find the docs for the old 0.6.x series Debian uses. This leads to confusion. I've been experimenting updating nodejs to 0.8.x and 0.9.x branches. Along the way I hit a number of issues and problems: * Recent npm and 0.8.x+ now uses node-gyp to compile native extensions. * node-gyp by default compiles extensions by downloading the upstream nodejs source and extracting headers into ~/.node-gyp/0.x.y/ and compiling against that. (I hear node-gyp has some nodedir magic option but I have no clue how to use it and can't find docs or code to help.) * The above means that node + node-gyp now REQUIRES nodejs to be built against the version of V8 that is shipped with whatever version of node you are running! * Debian nodejs 0.6.19 is linked with libv8 3.8.9.20. * Upstream nodejs 0.6.19 ships with libv8 3.6.6.25. * npm+node-gyp will build native modules with the 3.6.6.25 headers by default. * Load these modules nodejs running 3.8.9.20 and boom! Ok, not really "boom" most of the time. But you can see which symbols WILL break things with the previously mentioned site: http://www.upstream-tracker.org/versions/v8.html An example module that I just found today that will not work in Debian is memwatch. $ npm install memwatch ... build against 3.6.6.25... $ nodejs -e "require('memwatch')" ... run against 3.8.9.20 ... FAIL TO LOAD This is due to the V8::IdleNotification signature changing: http://www.upstream-tracker.org/compat_reports/v8/3.7.12.5_to_3.7.12.6/abi_compat_report.html 0.6.x has poor debugging of such issues. 0.8.x+ has a better error for what went wrong above. But if you comment out the IdleNotification line in the source the module will load IIRC. This is going to be a continual problem going forward. Some solutions: * Build nodejs with the non-shared shipped V8. * Build nodejs against the exact V8 version nodejs ships or one that is known to be ABI compatible. * Work with upstream authors to get a node-gyp that does the right thing when shared libs are used and/or teach all developers how to work around this issue. And just to make it messy, there are probably similar ABI issues for the other projects in the deps/ dir. A bit of good news is that a number of the debian/patches are not needed for 0.9.6 due to moving to allowing shared libs. But the problem of node-gyp building against the wrong libs still exists if you use the very latest V8. See http://www.upstream-tracker.org/compat_reports/v8/3.15.11.8_to_3.16.0/abi_compat_report.html I've partially updated the packaging for newer versions and found all these problems along the way. For end users using native modules it's going to be painful anytime nodejs gets updated. Everyone has to know to type "npm rebuild" or similar for all their projects. Yuck. Easiest short term solution for some of this is to lock nodejs to the V8 version it ships with. This would include updating the current package to use the older 3.6.6.25 V8 release. I'm guessing if this is done then we could update nodejs and v8 more frequently? How can I help get this update to happen? I say getting ready to update to 0.10.x when it comes out is a good target. -dave -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
