Debian and Fedora are trying to address the problem of dependencies

Linux distributions face the problem of increasing dependencies of the projects, although the number of dependencies for Python, Perl and Ruby code is kept Within reasonable limits, JavaScript projects practice dividing into very small libraries, often performing a simple function.

The NPM repository already has over a million packages and typical applications link to hundreds of dependencies, which in turn have their own dependencies, making it difficult to maintain and distribute traditional packages with JavaScript applications on Linux distributions.

Due to the tight intertwining of JavaScript library dependencies, updating any package with such libraries in a distribution it can break other packages.

Version bindings exacerbate the problem: one library may require one version of a dependency to run stable, and another may require another.

Many projects require the latest versions of the libraries to work, that do not always meet the stability requirements of the distribution (continuous development is practiced in the Node.js ecosystem using the latest versions of frameworks, and the distribution needs support for several years).

Attempts to fix package versions in the distribution alone lead to an increase in outdated versions in the repository that haven't been updated for years. Disruption of maintenance for one package adversely affects many other packages and creates even more problems.

In addition, lcross dependencies lead to the fact that many libraries of Node.js become impossible to uninstall from the system, which, in turn, prevents you from uninstalling other Node.js programs.

To deal with this situation, the Fedora project recently approved a plan to stop the default formation of separate packages with libraries used in Node.js-based projects.

He decided, starting with Fedora 34, to supply only base packages for Node.js with an interpreter, headers, primary libraries, binaries, and basic package management tools (NPM, yarn).

In Fedora repository applications that use Node.js, it is allowed to embed all existing dependencies in a package, without dividing and separating the libraries used in separate packages.

Embedding libraries will get rid of small package clutter, simplify package maintenance (previously the maintainer spent more time reviewing and testing hundreds of packages with libraries than in the main package with the program), save infrastructure from conflicts of libraries and resolve issues with linking to library versions (maintainers will include tested and production-tested versions in the package).

The downside of integration will be the complication of the process of bringing corrections vulnerabilities in the libraries, which will require a coordinated work of the maintainers of all the packages that include the vulnerable library. There is a danger that a package will forget to update a vulnerable built-in library and the package will go unnoticed.

The developers of Debian are also discussing switching to a similar package dependency integration model. In addition to Node.js, the discussion touches on the creation of packages for the Kubernetes platform and projects in the PHP and Go languages, for which there is a tendency to divide into small dependencies. No decision has yet been made, but it is hoped that over time the problem will only get worse and sooner or later the project will be forced to do something.

The gsa (Greenbone Security Assistant) web interface for the gvm (Greenbone Vulnerability Management) security scanner is cited as an example of the problems that package maintainers have.

The Debian-shipped version of gsa turned out to be incompatible with newer versions of gvm, but it was not possible to update gsa to the current version as it contains significant changes and uses npm to download the required Node.js libraries.

The requested libraries are too many and require the creation of new packages in Debian for someone to maintain them, as Debian rules forbid loading external components during the build process.


The content of the article adheres to our principles of editorial ethics. To report an error click here!.

A comment, leave yours

Leave a Comment

Your email address will not be published.



  1. Responsible for the data: Miguel Ángel Gatón
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.

  1.   Qtkk said

    This fragmentation of frameworks and libraries in ECMAscript has gotten out of hand.
    Good article.