System-files interface for enonic snap


I am Pavel with Enonic and I’d like to add a read-only access to system-files interface to enonic snap.

The original thread with app description can be found here

In a nutshel, enonic is a CLI for managing projects for Enonic XP CMS. Projects are usually tiny web-apps created from starters that we have ready and host on github, like this one. CLI downloads sources from github and helps to build and deploy it to Enonic XP CMS later.

We has been distributing through snap for around 3 years now and everything has been working smoothly until we supposedly did this commit which updated node.js version from one of our starter from v17 to v18.

Now we’re getting following error when trying to build that starter with CLI:

Building in sandbox 'hello'...

Welcome to Gradle 8.2.1!

Here are the highlights of this release:
 - Kotlin DSL: new reference documentation, assignment syntax by default
 - Kotlin DSL is now the default with Gradle init
 - Improved suggestions to resolve errors in console output
 - Reduced sync memory consumption

For more details see

Starting a Gradle Daemon, 1 incompatible Daemon could not be reused, use --status for details
> Task :compileJava NO-SOURCE
> Task :processResources
> Task :classes
> Task :nodeSetup
> Task :npmSetup SKIPPED

> Task :npmInstall FAILED

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to in the Gradle documentation.
3 actionable tasks: 3 executed
<-------------> 0% WAITING
node: /lib/x86_64-linux-gnu/ version `GLIBC_2.27' not found (required by node)
node: /lib/x86_64-linux-gnu/ version `GLIBC_2.25' not found (required by node)
node: /lib/x86_64-linux-gnu/ version `GLIBC_2.28' not found (required by node)

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':npmInstall'.
> Process 'command '/home/tomaj/code/testing/hello/.gradle/nodejs/node-v18.17.1-linux-x64/bin/npm'' finished with non-zero exit value 1

From what we can see Node.js started to look for dependencies in /lib folder on linux and we expect more starters to fail once updated to the latest Node.js version.

Googling it gave us the following:

while Node.js itself doesn’t explicitly require the GLIBC library, it depends on it indirectly because it is built and linked against the system libraries provided by the operating system, which includes GLIBC on most Linux distributions. This dependency on GLIBC ensures that Node.js can run on a wide range of Linux systems and can use standard C library functions and system calls for various operations.

So it looks like we just need to have access to system libs to be able to use latest Node.js:

    interface: system-files
    - /lib

Thank you for your time,

Pavel with Enonic


The system-files interface proposed above will break your snap by polluting the libraries in the search space and doesn’t guarantee that the host has the newer Glibc either. In order to give the snap a newer version of Glibc, you should attempt to upgrade the Snap from an older base to a newer one, such as core22, which will come with newer Glibc as standard.


Hi @James-Carroll !

Thank you for the prompt and spot-on reply ! Specifying snap core22 did the trick !

It was a bit of a surprise thought that latest core wasn’t used by default :wink:

Best regards, Pavel

I imagine that might be because you’re using Electron Forge or Electron Builder? Historically they’ve been quite conservative on the default bases and in my opinion it’s a shame because it means that stuff you’d get for “free” like newer GPU drivers, or font config libraries, etc, end up taking a lot longer in that ecosystem.

Personally I’d always prefer to build NodeJS/Electron the same as any other snap with Snapcraft since it gives the most direct control of the end result, but I can see why people prefer using one tool to do every release rather than treating the snap as a special case.

In any case, I’m glad the Core22 upgrade appears to have gone surprisingly smoothly for yourself!