After a conversation with Tom Hughes the other day, I started looking at Node.js 5.7.1 for Fedora 25. One of the things we discussed was that it probably makes sense for us to switch to carrying the bundled version of npm with the nodejs package, rather than trying to maintain its ever-growing list of dependencies without breaking npm itself.
I put together a COPR that all of the Node.js SIG member have access to at https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-latest/
Right now it has packages that should install on F23, F24 and Rawhide/F25 and will replace the npm package.
Please test your noarch and binary modules and let me know if anything is broken. Also, if you are a member of the Node.js SIG, feel free to rebuild your binary modules in the COPR to pick up the new Node.js ABI version.
These packages can be installed with: `dnf copr enable @nodejs-sig/nodejs-latest && dnf install nodejs`
On 08/03/16 21:32, Stephen Gallagher wrote:
I put together a COPR that all of the Node.js SIG member have access to at https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-latest/
Right now it has packages that should install on F23, F24 and Rawhide/F25 and will replace the npm package.
So two immediate observations after installing it in an F23 VM:
- It happily installs without forcing a libuv update and then doesn't work with missing uv_ symbols, so a better libuv require is needed
- The npm doesn't work at all because all the bundled modules are in the node_modules.bundled directory and node_modules is empty - moving them fixes it
Tom
On Mar 10, 2016, at 4:43 AM, Tom Hughes tom@compton.nu wrote:
On 08/03/16 21:32, Stephen Gallagher wrote:
I put together a COPR that all of the Node.js SIG member have access to at https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-latest/
Right now it has packages that should install on F23, F24 and Rawhide/F25 and will replace the npm package.
So two immediate observations after installing it in an F23 VM:
- It happily installs without forcing a libuv update and then doesn't
work with missing uv_ symbols, so a better libuv require is needed
Ok, that was an oversight.
- The npm doesn't work at all because all the bundled modules are in
the node_modules.bundled directory and node_modules is empty - moving them fixes it
Hmm, that's odd; it's supposed to contain symlinks to the bundled libraries. That's because the old NPM package had unbundled lobs symlinked in there and RPM can't replace a symlink with a directory. I'll look into it this morning.
Tom
-- Tom Hughes (tom@compton.nu) http://compton.nu/ _______________________________________________ nodejs mailing list nodejs@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/nodejs@lists.fedoraproject.org
On 03/10/2016 06:32 AM, Stephen Gallagher wrote:
On Mar 10, 2016, at 4:43 AM, Tom Hughes tom@compton.nu wrote:
On 08/03/16 21:32, Stephen Gallagher wrote:
I put together a COPR that all of the Node.js SIG member have access to at https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-latest/
Right now it has packages that should install on F23, F24 and Rawhide/F25 and will replace the npm package.
So two immediate observations after installing it in an F23 VM:
- It happily installs without forcing a libuv update and then doesn't
work with missing uv_ symbols, so a better libuv require is needed
Ok, that was an oversight.
I can't explain why, but it apparently worked fine in my testing with libuv 1.7.5, but I updated libuv and set the minimum to 1.8.0 anyway.
- The npm doesn't work at all because all the bundled modules are in
the node_modules.bundled directory and node_modules is empty - moving them fixes it
Hmm, that's odd; it's supposed to contain symlinks to the bundled libraries. That's because the old NPM package had unbundled lobs symlinked in there and RPM can't replace a symlink with a directory. I'll look into it this morning.
Aaand I forgot that in my testing I made this an "echo" statement instead of real symlinks. Oddly enough, `npm install <foo>` was working for me locally. I have no idea how...
I've just pushed a new update to the repository that also includes Node.js 5.8.0 (released yesterday). Of course, since the minor version jumped, binary packages may need a rebuild.
If we're going to look into supporting the rapidly-updating 5.x branch in F25, I wonder if we should modify the automatic dependency-generation to do: Requires: nodejs(abi) >= %{abi_major}.%{abi_minor} Conflicts: nodejs(abi) >= %{abi_major+1}
Of course, I have no idea how this automatic dependency is created, so I don't know how complicated it will be to fix. But I think we have to, since 5.x seems to bump minor versions at least once every couple months. Assuming it's properly following semantic versioning, the rebuild shouldn't actually be needed unless we bump the major version.
On 10/03/16 16:20, Stephen Gallagher wrote:
I've just pushed a new update to the repository that also includes Node.js 5.8.0 (released yesterday). Of course, since the minor version jumped, binary packages may need a rebuild.
If we're going to look into supporting the rapidly-updating 5.x branch in F25, I wonder if we should modify the automatic dependency-generation to do: Requires: nodejs(abi) >= %{abi_major}.%{abi_minor} Conflicts: nodejs(abi) >= %{abi_major+1}
Of course, I have no idea how this automatic dependency is created, so I don't know how complicated it will be to fix. But I think we have to, since 5.x seems to bump minor versions at least once every couple months. Assuming it's properly following semantic versioning, the rebuild shouldn't actually be needed unless we bump the major version.
Oh it's easy to do - the nodejs spec file creates nodejs_native.req in the %install section with those rules.
Why makes the second conflicts though? Why not:
Requires: nodejs(abi) >= %{abi_major}.%{abi_minor} Requires: nodejs(abi) < %{abi_major+1}
Which is what the dependency generator would do for a caret dependency on a node module.
Tom
On 03/10/2016 12:25 PM, Tom Hughes wrote:
On 10/03/16 16:20, Stephen Gallagher wrote:
I've just pushed a new update to the repository that also includes Node.js 5.8.0 (released yesterday). Of course, since the minor version jumped, binary packages may need a rebuild.
If we're going to look into supporting the rapidly-updating 5.x branch in F25, I wonder if we should modify the automatic dependency-generation to do: Requires: nodejs(abi) >= %{abi_major}.%{abi_minor} Conflicts: nodejs(abi) >= %{abi_major+1}
Of course, I have no idea how this automatic dependency is created, so I don't know how complicated it will be to fix. But I think we have to, since 5.x seems to bump minor versions at least once every couple months. Assuming it's properly following semantic versioning, the rebuild shouldn't actually be needed unless we bump the major version.
Oh it's easy to do - the nodejs spec file creates nodejs_native.req in the %install section with those rules.
Why makes the second conflicts though? Why not:
Requires: nodejs(abi) >= %{abi_major}.%{abi_minor} Requires: nodejs(abi) < %{abi_major+1}
Which is what the dependency generator would do for a caret dependency on a node module.
After some discussion on #fedora-devel, we opted to change the virtual Provides: to Provides: nodejs(abi%{nodejs_major}) = %{nodejs_major}.%{nodejs_minor}
and then the binary packages will get Requires: nodejs(abi%{nodejs_major}) >= %{nodejs_major}.%{nodejs_minor}
(or, without the variables:)
Provides: nodejs(abi5) = 5.8 Requires: nodejs(abi5) >= 5.8
The advantage this gives us is that if Node.js ever decides to offer two ABI versions together (such as if they have a total rewrite and thus opt to keep the old version around for a transition period), we'd be able to have Provides: nodejs(abiX) = X.Y and Provides: nodejs(abiX+1) = X+1.Z
This is now building in my COPR for 5.8. After this, we won't need to *force* a rebuild of a package unless the major Node version changes again.
On 03/10/2016 02:16 PM, Stephen Gallagher wrote:
On 03/10/2016 12:25 PM, Tom Hughes wrote:
On 10/03/16 16:20, Stephen Gallagher wrote:
I've just pushed a new update to the repository that also includes Node.js 5.8.0 (released yesterday). Of course, since the minor version jumped, binary packages may need a rebuild.
If we're going to look into supporting the rapidly-updating 5.x branch in F25, I wonder if we should modify the automatic dependency-generation to do: Requires: nodejs(abi) >= %{abi_major}.%{abi_minor} Conflicts: nodejs(abi) >= %{abi_major+1}
Of course, I have no idea how this automatic dependency is created, so I don't know how complicated it will be to fix. But I think we have to, since 5.x seems to bump minor versions at least once every couple months. Assuming it's properly following semantic versioning, the rebuild shouldn't actually be needed unless we bump the major version.
Oh it's easy to do - the nodejs spec file creates nodejs_native.req in the %install section with those rules.
Why makes the second conflicts though? Why not:
Requires: nodejs(abi) >= %{abi_major}.%{abi_minor} Requires: nodejs(abi) < %{abi_major+1}
Which is what the dependency generator would do for a caret dependency on a node module.
After some discussion on #fedora-devel, we opted to change the virtual Provides: to Provides: nodejs(abi%{nodejs_major}) = %{nodejs_major}.%{nodejs_minor}
and then the binary packages will get Requires: nodejs(abi%{nodejs_major}) >= %{nodejs_major}.%{nodejs_minor}
(or, without the variables:)
Provides: nodejs(abi5) = 5.8 Requires: nodejs(abi5) >= 5.8
The advantage this gives us is that if Node.js ever decides to offer two ABI versions together (such as if they have a total rewrite and thus opt to keep the old version around for a transition period), we'd be able to have Provides: nodejs(abiX) = X.Y and Provides: nodejs(abiX+1) = X+1.Z
This is now building in my COPR for 5.8. After this, we won't need to *force* a rebuild of a package unless the major Node version changes again.
Hmm, I'm not sure why this never got build, because I definitely submitted it. Anyway, I just started a build for 5.9.0 in my COPR, which includes this improved ABI check. Once we do a single rebuild against these new packages, it should work.
I'm planning to push the latest Node.js 5.x version to Fedora 25/Rawhide sometime next week, unless there is strong opposition. I'll announce it on Fedora devel-announce as well.
On 10/03/16 16:20, Stephen Gallagher wrote:
On 03/10/2016 06:32 AM, Stephen Gallagher wrote:
On Mar 10, 2016, at 4:43 AM, Tom Hughes tom@compton.nu wrote:
- The npm doesn't work at all because all the bundled modules are in the node_modules.bundled directory and node_modules is empty - moving them fixes it
Hmm, that's odd; it's supposed to contain symlinks to the bundled libraries. That's because the old NPM package had unbundled lobs symlinked in there and RPM can't replace a symlink with a directory. I'll look into it this morning.
Aaand I forgot that in my testing I made this an "echo" statement instead of real symlinks. Oddly enough, `npm install <foo>` was working for me locally. I have no idea how...
So this is still not quite right in the latest version - the node_modules directory now contains a symlink called "*" that points at the bundled directory.
What's the logic behind creating links anyway? Why not just put the modules in node_modules directly? or is what you're doing how upstream does it?
Tom
On 03/11/2016 03:33 AM, Tom Hughes wrote:
On 10/03/16 16:20, Stephen Gallagher wrote:
On 03/10/2016 06:32 AM, Stephen Gallagher wrote:
On Mar 10, 2016, at 4:43 AM, Tom Hughes tom@compton.nu wrote:
- The npm doesn't work at all because all the bundled modules are in the node_modules.bundled directory and node_modules is empty - moving them fixes it
Hmm, that's odd; it's supposed to contain symlinks to the bundled libraries. That's because the old NPM package had unbundled lobs symlinked in there and RPM can't replace a symlink with a directory. I'll look into it this morning.
Aaand I forgot that in my testing I made this an "echo" statement instead of real symlinks. Oddly enough, `npm install <foo>` was working for me locally. I have no idea how...
So this is still not quite right in the latest version - the node_modules directory now contains a symlink called "*" that points at the bundled directory.
What's the logic behind creating links anyway? Why not just put the modules in node_modules directly? or is what you're doing how upstream does it?
This is basically due to a long-standing bug in RPM. The current separate 'npm' package has: /usr/lib/node_modules/npm/node_modules/<a bunch of symlinks to unbundled modules>
We cannot upgrade to a new package that replaces a symlink-to-a-directory with a real directory. RPM can't handle that case and it throws conflict errors instead of doing the replacement. I don't know the details of why, but this has been true for many years and RPM developers say it won't be changing (probably a major architectural problem).
See: https://fedoraproject.org/wiki/Packaging:Directory_Replacement
So, there are two possible choices on how to deal with it: 1) Use a %pretrans scriptlet that deletes the existing links manually before the new package installs the new directory. 2) Move the new directories somewhere else and just update the links.
I chose to go with 2) because the problem with 1) is that it's much more painful to try to go from a directory to a symlink, so if we ever changed our mind, it's going to be hard to switch back.
Anyway, I'll look into why the symlink is still wrong. I must have typoed something. (I really wish I knew why everything still *worked* though...)
On 03/11/2016 03:33 AM, Tom Hughes wrote:
On 10/03/16 16:20, Stephen Gallagher wrote:
On 03/10/2016 06:32 AM, Stephen Gallagher wrote:
On Mar 10, 2016, at 4:43 AM, Tom Hughes tom@compton.nu wrote:
- The npm doesn't work at all because all the bundled modules are in the node_modules.bundled directory and node_modules is empty - moving them fixes it
Hmm, that's odd; it's supposed to contain symlinks to the bundled libraries. That's because the old NPM package had unbundled lobs symlinked in there and RPM can't replace a symlink with a directory. I'll look into it this morning.
Aaand I forgot that in my testing I made this an "echo" statement instead of real symlinks. Oddly enough, `npm install <foo>` was working for me locally. I have no idea how...
So this is still not quite right in the latest version - the node_modules directory now contains a symlink called "*" that points at the bundled directory.
OK, fixed. I was missing a %{builddir} in the FILES= line. It happened to work when building locally because those files were actually in my /usr, but not in mock.
New build running.
nodejs@lists.fedoraproject.org
-
Stephen Gallagher -
Tom Hughes