From Fedora Project Wiki
(Feedback section)
(Benefit)
Line 61: Line 61:
== Feedback ==
== Feedback ==


There has been a discussion on the fedora nodejs mailing list about what to do with the extreme dependency problem of the nodejs library packages.  Because of the extreme inter-dependency, upgrading almost any package causes others to break.  It has caused most packages to rot, upgraded for years.  Many of the nodejs packagers are giving up and orphaning their packages, which has caused even more problems.
There has been a discussion on the fedora nodejs mailing list about what to do with the extreme dependency problem of the nodejs library packages.  Because of the extreme inter-dependency, upgrading almost any package causes others to break.  It has caused most packages to rot, un-upgraded for years.  Many of the nodejs packagers are giving up and orphaning their packages, which has caused even more problems.


An initial proposal was to find all of the important nodejs library packages and bundle those, making them easier to upgrade and maintain.  But there was problems with figuring out what was important, and what versions should those have.  During that discussion this rather extreme solution, of getting rid of all nodejs libraries was proposed.  To our surprise, it has been the best suggestion and fixes the most problems.
An initial proposal was to find all of the important nodejs library packages and bundle those, making them easier to upgrade and maintain.  But there was problems with figuring out what was important, and what versions should those have.  During that discussion this rather extreme solution, of getting rid of all nodejs libraries was proposed.  To our surprise, it has been the best suggestion and fixes the most problems.
Line 67: Line 67:
== Benefit to Fedora ==
== Benefit to Fedora ==


<!-- What is the benefit to the distribution? Will the software we generate be improved? How will the process of creating Fedora releases be improved?
* In Fedora 33, there are many nodejs libraries that are uninstallable, causing other programs based off them, to also be uninstallable. This get's rid of that problem.
 
* Packages in Fedora that use nodejs libraries will be able to use the library versions that upstream has tested and approved.
      Be sure to include the following areas if relevant:
* If a package in Fedora uses a nodejs library that packager will not have to also package extra individual nodejs library packages. There have been times this has led to over 100 extra packages, each with their own package reviews and maintenance problems. This change will lower the workload on that packager, and possibly get more packages into Fedora.
      If this is a major capability update, what has changed?
* The nodejs maintainers can concentrate on nodejs itself, instead of the whole nodejs library infrastructure.
          For example: This change introduces Python 5 that runs without the Global Interpreter Lock and is fully multithreaded.
      If this is a new functionality, what capabilities does it bring?
          For example: This change allows package upgrades to be performed automatically and rolled-back at will.
      Does this improve some specific package or set of packages?
          For example: This change modifies a package to use a different language stack that reduces install size by removing dependencies.
      Does this improve specific Spins or Editions?
          For example: This change modifies the default install of Fedora Workstation to be more in line with the base install of Fedora Server.
      Does this make the distribution more efficient?
          For example: This change replaces thousands of individual %post scriptlets in packages with one script that runs at the end.
      Is this an improvement to maintainer processes?
          For example: Gating Fedora packages on automatic QA tests will make rawhide more stable and allow changes to be implemented more smoothly.
      Is this an improvement targeted as specific contributors?
          For example: Ensuring that a minimal set of tools required for contribution to Fedora are installed by default eases the onboarding of new contributors.  


    When a Change has multiple benefits, it's better to list them all.
    Consider these Change pages from previous editions as inspiration:
    https://fedoraproject.org/wiki/Changes/Annobin (low-level and technical, invisible to users)
    https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo (low-level, but visible to advanced users)
    https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration (primarily a UX change)
    https://fedoraproject.org/wiki/Changes/NoMoreAlpha (an improvement to distro processes)
    https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
-->


== Scope ==
== Scope ==

Revision as of 21:48, 23 September 2020

Idea.png
Guidance
For details on how to fill out this form, see the documentation.


Stop Shipping Individual Nodejs Library Packages

Summary

For Nodejs, Fedora should only package:

  • The interpreter, development headers/libraries, and the assorted tools to manage project-level installations (NPM, yarn, etc.).
  • Packages that provide binaries that users would want to use in their shell.
  • compiled/binary nodejs modules (for now)

Owner

  • Name: [Nodejs SIG]
  • Email: nodejs@lists.fedoraproject.org

Current status

  • Targeted release: Fedora 34
  • Last updated: 2020-09-23
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

The nodejs libraries have been approved to be bundled, and there is infrastructure in place for the bundling to work properly. Currently, it is recommended that packagers should create individual nodejs library packages instead of bundling all of the libraries into the package requiring them. This change is to make it default to bundle the nodejs libraries with the package that needs then, and retire the vast majority of nodejs library packages.

In summary, for Nodejs Fedora should only package:

  • The interpreter, development headers/libraries, and the assorted tools to manage project-level installations (NPM, yarn, etc.).
  • Packages that provide binaries that users would want to use in their shell.
  • compiled/binary nodejs modules (for now)


Feedback

There has been a discussion on the fedora nodejs mailing list about what to do with the extreme dependency problem of the nodejs library packages. Because of the extreme inter-dependency, upgrading almost any package causes others to break. It has caused most packages to rot, un-upgraded for years. Many of the nodejs packagers are giving up and orphaning their packages, which has caused even more problems.

An initial proposal was to find all of the important nodejs library packages and bundle those, making them easier to upgrade and maintain. But there was problems with figuring out what was important, and what versions should those have. During that discussion this rather extreme solution, of getting rid of all nodejs libraries was proposed. To our surprise, it has been the best suggestion and fixes the most problems.

Benefit to Fedora

  • In Fedora 33, there are many nodejs libraries that are uninstallable, causing other programs based off them, to also be uninstallable. This get's rid of that problem.
  • Packages in Fedora that use nodejs libraries will be able to use the library versions that upstream has tested and approved.
  • If a package in Fedora uses a nodejs library that packager will not have to also package extra individual nodejs library packages. There have been times this has led to over 100 extra packages, each with their own package reviews and maintenance problems. This change will lower the workload on that packager, and possibly get more packages into Fedora.
  • The nodejs maintainers can concentrate on nodejs itself, instead of the whole nodejs library infrastructure.


Scope

  • Proposal owners:
  • Other developers: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Objectives:

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

N/A (not a System Wide Change)

User Experience

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product

Documentation

N/A (not a System Wide Change)

Release Notes