#4 Build with a shared library.
Closed 2 years ago by sgallagh. Opened 2 years ago by qulogic.
rpms/ qulogic/nodejs master  into  master

@@ -0,0 +1,87 @@ 

+ From c38964d69ebb93e2273eca4bdcc4370fa26926f8 Mon Sep 17 00:00:00 2001

+ From: Elliott Sales de Andrade <quantum.analyst@gmail.com>

+ Date: Tue, 19 Mar 2019 23:22:40 -0400

+ Subject: [PATCH] Install both binaries and use libdir.

+ 

+ This allows us to build with a shared library for other users while

+ still providing the normal executable.

+ 

+ Signed-off-by: Elliott Sales de Andrade <quantum.analyst@gmail.com>

+ ---

+  configure.py     |  7 +++++++

+  tools/install.py | 31 ++++++++++++++-----------------

+  2 files changed, 21 insertions(+), 17 deletions(-)

+ 

+ diff --git a/configure.py b/configure.py

+ index b62be2302c..0924fa96dc 100755

+ --- a/configure.py

+ +++ b/configure.py

+ @@ -552,6 +552,12 @@ parser.add_option('--shared',

+      help='compile shared library for embedding node in another project. ' +

+           '(This mode is not officially supported for regular applications)')

+  

+ +parser.add_option('--libdir',

+ +    action='store',

+ +    dest='libdir',

+ +    default='lib',

+ +    help='a directory to install the shared library into')

+ +

+  parser.add_option('--without-v8-platform',

+      action='store_true',

+      dest='without_v8_platform',

+ @@ -1094,6 +1100,7 @@ def configure_node(o):

+    if options.code_cache_path:

+      o['variables']['node_code_cache_path'] = options.code_cache_path

+    o['variables']['node_shared'] = b(options.shared)

+ +  o['variables']['libdir'] = options.libdir

+    node_module_version = getmoduleversion.get_version()

+  

+    if sys.platform == 'darwin':

+ diff --git a/tools/install.py b/tools/install.py

+ index ce9ceeee1d..5ac67b714e 100755

+ --- a/tools/install.py

+ +++ b/tools/install.py

+ @@ -116,26 +116,23 @@ def subdir_files(path, dest, action):

+  

+  def files(action):

+    is_windows = sys.platform == 'win32'

+ -  output_file = 'node'

+    output_prefix = 'out/Release/'

+ +  output_libprefix = output_prefix

+  

+ -  if 'false' == variables.get('node_shared'):

+ -    if is_windows:

+ -      output_file += '.exe'

+ +  if is_windows:

+ +    output_bin = 'node.exe'

+ +    output_lib = 'node.dll'

+    else:

+ -    if is_windows:

+ -      output_file += '.dll'

+ -    else:

+ -      output_file = 'lib' + output_file + '.' + variables.get('shlib_suffix')

+ -      # GYP will output to lib.target except on OS X, this is hardcoded

+ -      # in its source - see the _InstallableTargetInstallPath function.

+ -      if sys.platform != 'darwin':

+ -        output_prefix += 'lib.target/'

+ -

+ -  if 'false' == variables.get('node_shared'):

+ -    action([output_prefix + output_file], 'bin/' + output_file)

+ -  else:

+ -    action([output_prefix + output_file], 'lib/' + output_file)

+ +    output_bin = 'node'

+ +    output_lib = 'libnode.' + variables.get('shlib_suffix')

+ +    # GYP will output to lib.target except on OS X, this is hardcoded

+ +    # in its source - see the _InstallableTargetInstallPath function.

+ +    if sys.platform != 'darwin':

+ +      output_libprefix += 'lib.target/'

+ +

+ +  action([output_prefix + output_bin], 'bin/' + output_bin)

+ +  if 'true' == variables.get('node_shared'):

+ +    action([output_libprefix + output_lib], variables.get('libdir') + '/' + output_lib)

+  

+    if 'true' == variables.get('node_use_dtrace'):

+      action(['out/Release/node.d'], 'lib/dtrace/node.d')

+ -- 

+ 2.20.1

+ 

file modified
+74 -20
@@ -1,5 +1,3 @@ 

- %global with_debug 1

- 

  # bundle dependencies that are not available as Fedora modules

  # %%{!?_with_bootstrap: %%global bootstrap 1}

  # use bcond for building modules
@@ -17,8 +15,9 @@ 

  %global nodejs_minor 15

  %global nodejs_patch 2

  %global nodejs_abi %{nodejs_major}.%{nodejs_minor}

+ %global nodejs_soversion 64

  %global nodejs_version %{nodejs_major}.%{nodejs_minor}.%{nodejs_patch}

- %global nodejs_release 1

+ %global nodejs_release 2

  

  # == Bundled Dependency Versions ==

  # v8 - from deps/v8/include/v8-version.h
@@ -122,11 +121,15 @@ 

  # Upstream patch to fix debug generation on PowerPC

  Patch3: 0003-deps-V8-cherry-pick-d0468de.patch

  

+ # Patch to install both node and libnode.so, using the correct libdir

+ Patch5: 0001-Install-both-binaries-and-use-libdir.patch

+ 

  BuildRequires: python2-devel

  BuildRequires: python3-devel

  BuildRequires: zlib-devel

  BuildRequires: gcc >= 4.9.4

  BuildRequires: gcc-c++ >= 4.9.4

+ BuildRequires: chrpath

  

  #%if ! 0%%{?bootstrap}

  %if %{with bootstrap}
@@ -154,6 +157,22 @@ 

  # we need the system certificate store

  Requires: ca-certificates

  

+ # Compatibility for obsolete v8 package

+ %ifarch %{ix86} x86_64 %{arm}

Also, don't bother wrapping it in this %ifarch here. We don't need to restrict it. The Provides won't cause any harm if they appear on packages that weren't used by the old v8 package.

+ %ifarch x86_64

Instead of this madness, use the %{__isa_bits} macro.

e.g. %if 0%{?__isa_bits} == 64

Right now, this approach will break on ppc64[le] and aarch64 (probably s390x as well).

+ Provides: libv8.so.%{v8_major}()(64bit)

+ Provides: libv8_libbase.so.%{v8_major}()(64bit)

+ Provides: libv8_libplatform.so.%{v8_major}()(64bit)

+ %else

+ Provides: libv8.so.%{v8_major}

+ Provides: libv8_libbase.so.%{v8_major}

+ Provides: libv8_libplatform.so.%{v8_major}

+ %endif

+ Provides: v8 = %{epoch}:%{v8_version}-%{nodejs_release}%{?dist}

+ Provides: v8%{?_isa} = %{epoch}:%{v8_version}-%{nodejs_release}%{?dist}

+ Obsoletes: v8 < 1:6.7.17-10

+ %endif

+ 

  #we need ABI virtual provides where SONAMEs aren't enough/not present so deps

  #break when binary compatibility is broken

  Provides: nodejs(abi) = %{nodejs_abi}
@@ -234,6 +253,14 @@ 

  %description devel

  Development headers for the Node.js JavaScript runtime.

  

+ %package -n v8-devel

+ Summary: v8 - development headers

+ Version: %{v8_version}

+ Requires: %{name}-devel%{?_isa} = %{epoch}:%{nodejs_version}-%{nodejs_release}%{?dist}

+ 

+ %description -n v8-devel

+ Development headers for the v8 runtime.

+ 

  %package -n npm

  Summary: Node.js Package Manager

  Epoch: %{npm_epoch}
@@ -311,6 +338,8 @@ 

  #%if ! 0%%{?bootstrap}

  %if %{with bootstrap}

  ./configure --prefix=%{_prefix} \

+            --shared \

+            --libdir=%{_lib} \

             --shared-openssl \

             --shared-zlib \

             --without-dtrace \
@@ -319,6 +348,8 @@ 

             --openssl-use-def-ca-store

  %else

  ./configure --prefix=%{_prefix} \

+            --shared \

+            --libdir=%{_lib} \

             --shared-openssl \

             --shared-zlib \

             --shared-libuv \
@@ -330,12 +361,7 @@ 

             --openssl-use-def-ca-store

  %endif

  

- %if %{?with_debug} == 1

- # Setting BUILDTYPE=Debug builds both release and debug binaries

- make BUILDTYPE=Debug %{?_smp_mflags}

- %else

  make BUILDTYPE=Release %{?_smp_mflags}

- %endif

  

  

  %install
@@ -345,11 +371,22 @@ 

  

  # Set the binary permissions properly

  chmod 0755 %{buildroot}/%{_bindir}/node

- 

- %if %{?with_debug} == 1

- # Install the debug binary and set its permissions

- install -Dpm0755 out/Debug/node %{buildroot}/%{_bindir}/node_g

+ chrpath --delete %{buildroot}%{_bindir}/node

+ 

+ # Install library symlink

+ ln -s %{_libdir}/libnode.so.%{nodejs_soversion} %{buildroot}%{_libdir}/libnode.so

+ 

+ # Install v8 compatibility symlinks

+ for header in %{buildroot}%{_includedir}/node/libplatform %{buildroot}%{_includedir}/node/v8*.h; do

+     header=$(basename ${header})

+     ln -s %{_includedir}/node/${header} %{buildroot}%{_includedir}/${header}

+ done

+ for soname in libv8 libv8_libbase libv8_libplatform; do

+     ln -s %{_libdir}/libnode.so.%{nodejs_soversion} %{buildroot}%{_libdir}/${soname}.so

+ %ifarch %{ix86} x86_64 %{arm}

+     ln -s %{_libdir}/libnode.so.%{nodejs_soversion} %{buildroot}%{_libdir}/${soname}.so.%{v8_major}

  %endif

+ done

  

  # own the sitelib directory

  mkdir -p %{buildroot}%{_prefix}/lib/node_modules
@@ -414,15 +451,15 @@ 

  

  %check

  # Fail the build if the versions don't match

- %{buildroot}/%{_bindir}/node -e "require('assert').equal(process.versions.node, '%{nodejs_version}')"

- %{buildroot}/%{_bindir}/node -e "require('assert').equal(process.versions.v8.replace(/-node\.\d+$/, ''), '%{v8_version}')"

- %{buildroot}/%{_bindir}/node -e "require('assert').equal(process.versions.ares.replace(/-DEV$/, ''), '%{c_ares_version}')"

+ LD_LIBRARY_PATH=%{buildroot}%{_libdir} %{buildroot}/%{_bindir}/node -e "require('assert').equal(process.versions.node, '%{nodejs_version}')"

+ LD_LIBRARY_PATH=%{buildroot}%{_libdir} %{buildroot}/%{_bindir}/node -e "require('assert').equal(process.versions.v8.replace(/-node\.\d+$/, ''), '%{v8_version}')"

+ LD_LIBRARY_PATH=%{buildroot}%{_libdir} %{buildroot}/%{_bindir}/node -e "require('assert').equal(process.versions.ares.replace(/-DEV$/, ''), '%{c_ares_version}')"

  

  # Ensure we have punycode and that the version matches

- %{buildroot}/%{_bindir}/node -e "require(\"assert\").equal(require(\"punycode\").version, '%{punycode_version}')"

+ LD_LIBRARY_PATH=%{buildroot}%{_libdir} %{buildroot}/%{_bindir}/node -e "require(\"assert\").equal(require(\"punycode\").version, '%{punycode_version}')"

  

  # Ensure we have npm and that the version matches

- NODE_PATH=%{buildroot}%{_prefix}/lib/node_modules:%{buildroot}%{_prefix}/lib/node_modules/npm/node_modules %{buildroot}/%{_bindir}/node -e "require(\"assert\").equal(require(\"npm\").version, '%{npm_version}')"

+ NODE_PATH=%{buildroot}%{_prefix}/lib/node_modules:%{buildroot}%{_prefix}/lib/node_modules/npm/node_modules LD_LIBRARY_PATH=%{buildroot}%{_libdir} %{buildroot}/%{_bindir}/node -e "require(\"assert\").equal(require(\"npm\").version, '%{npm_version}')"

  

  

  %pretrans -n npm -p <lua>
@@ -442,6 +479,12 @@ 

  

  %files

  %{_bindir}/node

+ %{_libdir}/libnode.so.%{nodejs_soversion}

+ %ifarch %{ix86} x86_64 %{arm}

+ %{_libdir}/libv8.so.%{v8_major}

+ %{_libdir}/libv8_libbase.so.%{v8_major}

+ %{_libdir}/libv8_libplatform.so.%{v8_major}

+ %endif

  %dir %{_prefix}/lib/node_modules

  %dir %{_datadir}/node

  %dir %{_datadir}/systemtap
@@ -464,14 +507,20 @@ 

  

  

  %files devel

- %if %{?with_debug} == 1

- %{_bindir}/node_g

- %endif

  %{_includedir}/node

+ %{_libdir}/libnode.so

  %{_datadir}/node/common.gypi

  %{_pkgdocdir}/gdbinit

  

  

+ %files -n v8-devel

+ %{_includedir}/libplatform

+ %{_includedir}/v8*.h

+ %{_libdir}/libv8.so

+ %{_libdir}/libv8_libbase.so

+ %{_libdir}/libv8_libplatform.so

+ 

+ 

  %files -n npm

  %{_bindir}/npm

  %{_bindir}/npx
@@ -493,6 +542,11 @@ 

  %{_pkgdocdir}/npm/doc

  

  %changelog

+ * Sun Mar 17 2019 Elliott Sales de Andrade <quantum.analyst@gmail.com> - 1:10.15.2-2

+ - Drop debug executable

+ - Build with a shared library

+ - Add v8 compatibility subpackage

+ 

  * Fri Mar 01 2019 Stephen Gallagher <sgallagh@redhat.com> - 1:10.15.2-1

  - Update to 10.15.2

  - https://nodejs.org/en/blog/release/v10.15.1/

I basically copied what Debian does to create the shared version.

This does work for me to build R-V8 against the shared library: https://copr.fedorainfracloud.org/coprs/qulogic/nodejs-R-V8/builds/ (note: copr seems to have trouble building x86_64, so ignore that; it works locally.)

Could you do this as a patch instead of a sed command? I'd prefer to have a patch that fails to apply if this file is changed, so we know if we need to take action to update it.

I think you need to update this too to use the shared library and change the rpath, don't you?

Wouldn't this be difficult to do as a patch, since you need either it to be lib or lib64?

Wouldn't this be difficult to do as a patch, since you need either it to be lib or lib64?

Oof, you are right of course. I didn't think that through carefully. I misread what it was doing there.

That regexp may be a little overzealous, though. What happens if install.py ends up including a path like ../foolib/stuff.so? I'm always wary of sed-based solutions. (I don't love the python hashbang solution in here either, but it's impossible to do otherwise)

Thanks for looking into this! @qulogic do I need to make any changes in the V8 configure script for it to find this libnode ?

I think you need to update this too to use the shared library and change the rpath, don't you?

Actually, I don't know about what this does, really. With the shared library enabled, we have two of them:

<mock-chroot> sh-5.0# ll out/*/node out/*/lib.target/libnode.so.64 
-rwxr-xr-x. 2 mockbuild mock 934039424 Mar  8 05:56 out/Debug/lib.target/libnode.so.64
-rwxr-xr-x. 1 mockbuild mock     45184 Mar  8 05:56 out/Debug/node
-rwxr-xr-x. 2 mockbuild mock 785401600 Mar  8 05:54 out/Release/lib.target/libnode.so.64
-rwxr-xr-x. 1 mockbuild mock     45264 Mar  8 05:54 out/Release/node

While they aren't the same size, they're both gigantic and way larger than the final (debug-stripped) thing in the rpm, but which one should be installed?

@jeroenooms Yes, I did apply a small patch to the search paths, but don't worry, I can send a PR once we've worked out the details here and it's confirmed to work.

Since I'm already rewriting the libdir thing as a patch, I might be able to get these parallel-installable by renaming to libnode_g.so.64. Or would using the alternatives system be more desirable here?

@jeroenooms Yes, I did apply a small patch to the search paths, but don't worry, I can send a PR once we've worked out the details here and it's confirmed to work.

OK thank you. Ideally we would follow the convention from debian and make the proper symlinks:

/usr/include/v8 -> /usr/include/node
/usr/lib64/libv8.so -> /usr/lib64/libnode.so
/usr/lib64/libv8_platform.so -> /usr/lib64/libnode.so

Thereby the R package and other bindings can compile with -I/usr/include/v8 and link with -lv8 -lv8_platform as expected, without having to special case for node.

Since I'm already rewriting the libdir thing as a patch, I might be able to get these parallel-installable by renaming to libnode_g.so.64. Or would using the alternatives system be more desirable here?

When you say you're rewriting it as a patch, do you mean you're fixing the node build to honor --libdir or something like that?

Please do not use alternatives for this. I think renaming it to libnode_g.so.64 is the better approach.

OK thank you. Ideally we would follow the convention from debian and make the proper symlinks:

Hmm, maybe we can do that; I guess that depends on what @sgallagh wants to do; maybe provide a compat-* sort of package?

When you say you're rewriting it as a patch, do you mean you're fixing the node build to honor --libdir or something like that?

Yes.

Unfortunately, getting the debug executable working turned out to be more work than anticipated. While gyp seems to have keyed many things off of BUILDTYPE (e.g., CFLAGS, etc.), it doesn't appear possible to set the target name based on it. This causes trouble for the renaming since node_g has DT_NEEDED: libnode.so.64.

It could be fixed with something like patchelf, but the version in Rawhide seems to be buggy. After changing DT_NEEDED and stripping, the executable is totally broken. It may be fixed in master, but we don't carry any of those patches.

I guess the only option is to place the debug library in some separate location (e.g., /usr/libexec/node-debug/) and add an rpath to the executable. Unless someone else has a different idea?

Honestly, I have no idea if anyone at all uses the debug version of the binary. I've kept it around since the original packager had included it, but no one has ever filed a bug when I've disabled it on certain arches for a while when they didn't build (variously PPC64le, aarch64, etc. at different times).

I'm open to just killing the debug build entirely and seeing if anyone complains.

As for creating the libnode symlinks, I'm fine with just doing that in the main and -devel packages. No need for a compat- subpackage. There is no existing package in the distro that owns those names, so we may as well carry them.

Check to see if creating those symlinks causes the dependency generator to create virtual Provides for them, though. If not, you may need to do it manually to deal with things that link against them implicitly. I'm not sure how the generators work with symlinks of libraries that change the base name.

Check to see if creating those symlinks causes the dependency generator to create virtual Provides for them, though. If not, you may need to do it manually to deal with things that link against them implicitly. I'm not sure how the generators work with symlinks of libraries that change the base name.

They will follow the links to the original file and read the soname from that. So you'll need to put Provides for the name for compatibility purposes until everything is relinked.

Check to see if creating those symlinks causes the dependency generator to create virtual Provides for them, though. If not, you may need to do it manually to deal with things that link against them implicitly. I'm not sure how the generators work with symlinks of libraries that change the base name.

They will follow the links to the original file and read the soname from that. So you'll need to put Provides for the name for compatibility purposes until everything is relinked.

I'm not sure Provides are necessary in that case. They'll just be linked against the libnode.so.64 library. That should handle things fine, or am I missing something?

@sgallagh If the purpose is to offer a seamless transition without requiring everything dependent on the v8 package to be rebuilt, it'd be necessary. If you intend to require a rebuild, it will be unnecessary, and you just need Obsoletes + Provides for v8 in the package containing the symlinks.

OK, I didn't quite know how far back you were backporting this, as I don't know where those modules go. F29 still has v8 in it, so if it's going there and need Conflicts, I'd rather add a separate compat-v8-devel-type thing.

I've updated this to drop the node_g binary, and converted the sed to a patch, but haven't yet added the compatibility symlinks. Dropping the node_g has a side benefit of building way faster. It takes half the time on copr compared to old working builds, and no longer gets stuck for days. Locally it seems about a 1/3 or 1/4 of the time.

rebased onto 31053fb

2 years ago

FYI the maintainer of the previous v8 package obsoleted it because nothing formally depends on it, currently. So perhaps the rebuilding should not be a concern.

FYI the maintainer of the previous v8 package obsoleted it because nothing formally depends on it, currently. So perhaps the rebuilding should not be a concern.

To avoid terminology confusion, it was retired, not obsoleted. The new subpackage this is building should be made to Obsoletes: that v8 package. I'm not clear on whether it should also Provides: v8 = %{v8_version}. I don't know enough about how compatible the Node version (6.8) is with the previous v8 version (6.7).

I'm not clear on whether it should also Provides: v8 = %{v8_version}.

The node release table shows that version of libv8 that was bundled with node 10.x was initially 6.6 and then 6.7 and later bumped to 6.8. Therefore I think the API can be considered practically backward-compatible.

Also I doubt that anyone or anything was seriously using the previous v8 package before it got retired, so maybe backward compatibility is not super important...

1 new commit added

  • Add v8 compatibility subpackage.
2 years ago

I pushed some compatibility development/build symlinks and this is sufficient to build R-V8 without any patches: https://copr.fedorainfracloud.org/coprs/qulogic/nodejs-R-V8/builds/

I did not add any runtime v8 symlinks as one of the reasons that v8 was retired is that nothing uses it. So I see no reason to add Provides: v8 or any symlinks for it.

Please don't call it compat-v8-devel. The compat- prefix has been phased out, and it's not what this package does anyway. It is sufficient to just call it v8-devel or nodejs-v8-devel.

3 new commits added

  • Add v8 compatibility subpackage.
  • Build with a shared library.
  • Drop the debug executable.
2 years ago

OK, removed the compat- prefix.

Can you please make this a Git-style patch with attribution and description, similar to the other patches?

If we want to avoid needing to rebuild those packages that currently depend on v8 in Fedora, we should be having this link to libv8.so.6, libbase.so.6 and libplatform.so.6.

@sgallagh And avoiding rebuilding those packages also will require fake Provides for those.

I don't think we can really avoid doing that, unfortunately. We can't know what packages outside the distro might be using the v8-provided libraries. So we need to generate those provides, which is... ugly.

For example, on x86_64 v8 Provides:

libv8.so.6()(64bit)
libv8_libbase.so.6()(64bit)
libv8_libplatform.so.6()(64bit)
v8 = 1:6.7.17-8.fc30
v8(x86-64) = 1:6.7.17-8.fc30

on armv7hl:

libv8.so.6
libv8_libbase.so.6
libv8_libplatform.so.6
v8 = 1:6.7.17-8.fc30
v8(armv7hl-32) = 1:6.7.17-8.fc30

and on i686:

libv8.so.6
libv8_libbase.so.6
libv8_libplatform.so.6
v8 = 1:6.7.17-8.fc30
v8(x86-32) = 1:6.7.17-8.fc30

On the plus side, the existing v8 package only supports these three architectures, so we don't need to worry about backwards-compatibility on the others.

There is no existing package in the distro that owns those names, so we may as well carry them.

If you're saying this, then you could only be targeting F30+. Then there are no packages in the distro that depend on v8 (they've all been retired) and no in-distro reason for the Provides. And for out-of-distro, we bump sonames (in Rawhide mostly) all the time and don't add Provides for them.

So I'm not really convinced, but I've added them. I don't know how to get the ()(64bit) from a macro, so I just put it in %ifarch x86_64.

3 new commits added

  • Add v8 compatibility subpackage.
  • Build with a shared library.
  • Drop the debug executable.
2 years ago

To give some more background: The v8 (version6) rpm was recently introduced fairly recently by @spot to phase out the old v8-314 rpm. FC28 shipped with v8 version 6.2 which was upgraded to version 6.8 in FC29, and these are already incompatible. So the benefit of making node-devel in FC30 binary compatible with FC29 v8-devel is limited to applications that were specifically written for the F29 version of v8-devel, which seems unlikely.

Any progress on this? There are a lot of R users who would love to the R package V8 in F30 and up!

Instead of this madness, use the %{__isa_bits} macro.

e.g. %if 0%{?__isa_bits} == 64

Right now, this approach will break on ppc64[le] and aarch64 (probably s390x as well).

Also, don't bother wrapping it in this %ifarch here. We don't need to restrict it. The Provides won't cause any harm if they appear on packages that weren't used by the old v8 package.

OK, I've worked up a follow-up patch to make the adjustments I mentioned above. I'm still not entirely sure why we're using %{_lib} instead of %{_libdir} in the configure step, but I'm not invested enough to change it.

I split out the libraries into a nodejs-libs subpackage, cleaned up the virtual Provides as discussed above and then set the epoch on v8-devel to ensure the upgrade path is clean.

I'm running a scratch-build now at https://koji.fedoraproject.org/koji/taskinfo?taskID=34079564 for all architectures before I merge this work and do official builds. Testing recommended.

The complete patch atop this PR:

From 5316e1dc6c8cb08d630d6f5ec0a6ad8646a84d06 Mon Sep 17 00:00:00 2001
From: Stephen Gallagher <sgallagh@redhat.com>
Date: Tue, 9 Apr 2019 10:40:26 -0400
Subject: [PATCH] Split libnode into a nodejs-libs subpackage

Clean up provides and epoch

Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
---
 nodejs.spec | 61 ++++++++++++++++++++++++++++++++++-------------------
 1 file changed, 39 insertions(+), 22 deletions(-)

diff --git a/nodejs.spec b/nodejs.spec
index 3a0e62cb8086a2079e46f6a08dbf7cf530d54c5c..218383f37defc02e1777a29c90507438fe705ffa 100644
--- a/nodejs.spec
+++ b/nodejs.spec
@@ -15,14 +15,16 @@
 %global nodejs_minor 15
 %global nodejs_patch 2
 %global nodejs_abi %{nodejs_major}.%{nodejs_minor}
 %global nodejs_soversion 64
 %global nodejs_version %{nodejs_major}.%{nodejs_minor}.%{nodejs_patch}
-%global nodejs_release 2
+%global nodejs_release 3

 # == Bundled Dependency Versions ==
 # v8 - from deps/v8/include/v8-version.h
+# Epoch is set to ensure clean upgrades from the old v8 package
+%global v8_epoch 1
 %global v8_major 6
 %global v8_minor 8
 %global v8_build 275
 %global v8_patch 32
 # V8 presently breaks ABI at least every x.y release while never bumping SONAME
@@ -155,25 +157,12 @@ BuildRequires: libicu-devel >= 62.1
 BuildRequires: openssl-devel

 # we need the system certificate store
 Requires: ca-certificates

-# Compatibility for obsolete v8 package
-%ifarch %{ix86} x86_64 %{arm}
-%ifarch x86_64
-Provides: libv8.so.%{v8_major}()(64bit)
-Provides: libv8_libbase.so.%{v8_major}()(64bit)
-Provides: libv8_libplatform.so.%{v8_major}()(64bit)
-%else
-Provides: libv8.so.%{v8_major}
-Provides: libv8_libbase.so.%{v8_major}
-Provides: libv8_libplatform.so.%{v8_major}
-%endif
-Provides: v8 = %{epoch}:%{v8_version}-%{nodejs_release}%{?dist}
-Provides: v8%{?_isa} = %{epoch}:%{v8_version}-%{nodejs_release}%{?dist}
-Obsoletes: v8 < 1:6.7.17-10
-%endif
+Requires: nodejs-libs%{?_isa} = %{epoch}:%{nodejs_version}-%{nodejs_release}%{?dist}
+

 #we need ABI virtual provides where SONAMEs aren't enough/not present so deps
 #break when binary compatibility is broken
 Provides: nodejs(abi) = %{nodejs_abi}
 Provides: nodejs(abi%{nodejs_major}) = %{nodejs_abi}
@@ -251,12 +240,34 @@ Requires: libuv-devel%{?_isa}
 %endif

 %description devel
 Development headers for the Node.js JavaScript runtime.

+%package libs
+Summary: Node.js and v8 libraries
+
+# Compatibility for obsolete v8 package
+%if 0%{?__isa_bits} == 64
+Provides: libv8.so.%{v8_major}()(64bit)
+Provides: libv8_libbase.so.%{v8_major}()(64bit)
+Provides: libv8_libplatform.so.%{v8_major}()(64bit)
+%else # 32-bits
+Provides: libv8.so.%{v8_major}
+Provides: libv8_libbase.so.%{v8_major}
+Provides: libv8_libplatform.so.%{v8_major}
+%endif
+
+Provides: v8 = %{v8_epoch}:%{v8_version}-%{nodejs_release}%{?dist}
+Provides: v8%{?_isa} = %{v8_epoch}:%{v8_version}-%{nodejs_release}%{?dist}
+Obsoletes: v8 < 1:6.7.17-10
+
+%description libs
+Libraries to support Node.js and provide stable v8 interfaces.
+
 %package -n v8-devel
 Summary: v8 - development headers
+Epoch: %{v8_epoch}
 Version: %{v8_version}
 Requires: %{name}-devel%{?_isa} = %{epoch}:%{nodejs_version}-%{nodejs_release}%{?dist}

 %description -n v8-devel
 Development headers for the v8 runtime.
@@ -477,16 +488,10 @@ if d_st then
   end
 end

 %files
 %{_bindir}/node
-%{_libdir}/libnode.so.%{nodejs_soversion}
-%ifarch %{ix86} x86_64 %{arm}
-%{_libdir}/libv8.so.%{v8_major}
-%{_libdir}/libv8_libbase.so.%{v8_major}
-%{_libdir}/libv8_libplatform.so.%{v8_major}
-%endif
 %dir %{_prefix}/lib/node_modules
 %dir %{_datadir}/node
 %dir %{_datadir}/systemtap
 %dir %{_datadir}/systemtap/tapset
 %{_datadir}/systemtap/tapset/node.stp
@@ -511,10 +516,17 @@ end
 %{_libdir}/libnode.so
 %{_datadir}/node/common.gypi
 %{_pkgdocdir}/gdbinit


+%files libs
+%{_libdir}/libnode.so.%{nodejs_soversion}
+%{_libdir}/libv8.so.%{v8_major}
+%{_libdir}/libv8_libbase.so.%{v8_major}
+%{_libdir}/libv8_libplatform.so.%{v8_major}
+
+
 %files -n v8-devel
 %{_includedir}/libplatform
 %{_includedir}/v8*.h
 %{_libdir}/libv8.so
 %{_libdir}/libv8_libbase.so
@@ -540,10 +552,15 @@ end
 %{_pkgdocdir}/html
 %{_pkgdocdir}/npm/html
 %{_pkgdocdir}/npm/doc

 %changelog
+* Tue Apr 09 2019 Stephen Gallagher <sgallagh@redhat.com> - 1:10.15.2-3
+- Separate nodejs-libs out to its own subpackage
+- Clean up compatibility virtual Provides
+- Set epoch for v8-devel to maintain upgrade path
+
 * Sun Mar 17 2019 Elliott Sales de Andrade <quantum.analyst@gmail.com> - 1:10.15.2-2
 - Drop debug executable
 - Build with a shared library
 - Add v8 compatibility subpackage

-- 
2.21.0

Scratch build failed because I missed one place where the architectures were being overspecified. I'll amend my patch with the following if this new scratch build completes successfully:

From 6d2876b4e88822bd81d603f6db4b52a2e3af8953 Mon Sep 17 00:00:00 2001
From: Stephen Gallagher <sgallagh@redhat.com>
Date: Tue, 9 Apr 2019 13:30:26 -0400
Subject: [PATCH] fixup! Split libnode into a nodejs-libs subpackage

Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
---
 nodejs.spec | 2 --
 1 file changed, 2 deletions(-)

diff --git a/nodejs.spec b/nodejs.spec
index 218383f37defc02e1777a29c90507438fe705ffa..f42933a3d3b358b9fb5ad57ced040003bd0b15b0 100644
--- a/nodejs.spec
+++ b/nodejs.spec
@@ -392,13 +392,11 @@ for header in %{buildroot}%{_includedir}/node/libplatform %{buildroot}%{_include
     header=$(basename ${header})
     ln -s %{_includedir}/node/${header} %{buildroot}%{_includedir}/${header}
 done
 for soname in libv8 libv8_libbase libv8_libplatform; do
     ln -s %{_libdir}/libnode.so.%{nodejs_soversion} %{buildroot}%{_libdir}/${soname}.so
-%ifarch %{ix86} x86_64 %{arm}
     ln -s %{_libdir}/libnode.so.%{nodejs_soversion} %{buildroot}%{_libdir}/${soname}.so.%{v8_major}
-%endif
 done

 # own the sitelib directory
 mkdir -p %{buildroot}%{_prefix}/lib/node_modules

-- 
2.21.0

OK, that most recent scratch-build worked and seems to be working for me. I'd appreciate if someone on this PR thread could test it and validate that it's working for them. If so, I'll get this pushed ASAP

Fantastic! If @qulogic's R-V8 build works with this version, we are all set.

Should nodejs-devel depend on nodejs or the new nodejs-libs now?

Should nodejs-devel depend on nodejs or the new nodejs-libs now?

It's the -devel package for nodejs, not for nodejs-libs. It should remain depending on nodejs, which in turn depends on nodejs-libs. I also don't want to break expectations for anyone currently using Requires: nodejs-devel such that they suddenly do not have the nodejs interpreter.

The new version works for building R-V8 locally in mock for me, and I can run most of the introductory vignette with it.

OK, perfect. I'll get this merged and built tonight. Thanks for testing!

This is now merged to the "10", "master", "f30" and "f29" branches. I've got traditional builds in-flight for f29+ as well as modules for F28+.

Bodhi updates will come in the morning.

Pull-Request has been closed by sgallagh

2 years ago

Bodhi updates have been submitted for F29 and F30. Also modular builds for F29+.

I've created buildroot overrides on F29 and F30 so anyone who wants to build against v8-devel can do so.

OK fantastic. I am going to test this with more R packages that depend on the V8 package.

I'm not super familiar with the Fedora infrastructure, when do these updates become available in the standard repositories? I started a fedora:rawhide docker container and tried to install nodejs-devel and R-V8 but it would still download the old versions (nodejs-devel-1:10.15.2-1.fc31.x86_64)

@jeroenooms For Rawhide, they generally show up the next day, but there was a compose problem and it's still running. Should happen sometime today.

For the other releases (e.g. F30), it usually takes between 24-48 hours to hit the mirrors and until they are moved from the testing repos to the stable repos, you'll need to add --enablerepo=*-testing to install them.

@qulogic did you need any patches to make R-V8 work? Then I will apply them upstream for the next release. Also is it still possible to port the new R-V8 to F30?

Nope. 2.2 is already in F30.

@qulogic R-V8 2.2 is in F30 testing currently. Can you push it to stable?