Wiki - https://fedoraproject.org/wiki/Changes/FoomaticRipRejectsUnknownValues
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-foomatic-rip-rej…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
The filter `foomatic-rip` will reject any values of PPD options
`FoomaticRIPCommandLine`, `FoomaticRIPCommandLinePDF`, and
`FoomaticRIPOptionSetting`. Users are able to scan drivers of their
installed printers by the tool `foomatic-hash`, which outputs a file
which is used for allowing the found values for the filter.
== Owner ==
* Name: [[User:zdohnal| Zdenek Dohnal]]
* Email: zdohnal(a)redhat.com
== Detailed Description ==
The filter `foomatic-rip` supports several PPD options which are used
to construct a shell command, which is to be run in a new process.
Those options are `FoomaticRIPCommandLine`,
`FoomaticRIPCommandLinePDF`, and `FoomaticRIPOptionSettings`. This
behavior was implemented around 20 years ago to help printer vendors
or enthusiasts with writing printer drivers for Linux. Driver creators
did not have to write a new filter which would apply requested changes
into a filtered file, but wrote set of shell commands, Postscript code
or Perl code which were applied to the print job before sending it to
the printer.
However this approach is often the final goal of attackers, who
exploit another security vulnerabilities in the printing stack to get
users to install and use a malicious PPD file for their printer, which
will contain crafted mentioned PPD options. Such issues are mitigated
by `foomatic-rip` being run under user `lp` in the default
configuration.
To prevent unintentional use of malicious foomatic-related PPD
options, the filter won't accept any values by default. As a way how
to review and create an allowed list of safe values, the tool
`foomatic-hash` is implemented.
The tool `foomatic-hash` scans a PPD file or a path with drivers
defined on its command line and outputs two files - one with found
values for users to review, and the other with the found values hashed
and ready to be copied into directories where `foomatic-rip` reads
them.
In new Fedora 43 installations users are expected to run
`foomatic-hash` tool, review the scan findings and allow the found
values by moving the file with hashes into the directory
`/etc/foomatic/hashes.d`.
== Feedback ==
1. Will we allow every foomatic-related PPD options values which are
already in Fedora?
Since `foomatic-rip` is mostly used with older printers or with
printers which have another support alternative (like AirPrint), and
there are many such older drivers for printers which are now not used
often, there would be many values to review for printing stack
maintainers in comparison to additional value it gains for Fedora.
However the package cups-filters provides a directory which is read by
`foomatic-rip` in case a printer driver wants to review and ship
allowed hashes. The directory `/usr/share/foomatic/hashes.d` is
present for this purpose and developers can install their files with
allowed hashes into this directory.
2. Will the previously installed print queue be working after upgrade?
Based on this feedback the proposal owner will implement a RPM
scriptlet which will allow values from installed printers, which were
installed in the previous Fedora version. A message will be generated
during DNF upgrade if there are print queues with such drivers, and
direct user to `foomatic-rip` man page.
3. Is it possible to sanitize the values instead of introducing
reject/allow mechanism?
Unfortunately this is not possible due functionality of those options.
They were meant to construct a shell command, so we cannot forbid
interpreter calls or remove/escape special characters since it would
break the correct shell command.
== Benefit to Fedora ==
The change improves Fedora security while leaving a way for users who
depend on the driver with the filter foomatic-rip to allow their
drivers.
== Scope ==
* Proposal owners:
Proposal owner will apply the upstream patch implementing the issue,
and test upgrade path.
* Other developers:
(optional) Printer driver maintainers might scan drivers provided by
their package, review the findings and if there is no discrepancies,
ship the file with hashed values at directory
`/usr/share/foomatic/hashes.d`.
* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
Upgrade from Fedora 42 to Fedora 43 will allow the values of already
installed printers to maintain functionality, but users are expected
to review the file with found values. The file with findings will be
present in the directory `/var/tmp` in the file with prefix
`foomatic-scan`.
== How To Test ==
How to find out if drivers with `foomatic-rip` are used with the
currently installed printers:
<pre>
$ sudo grep -Rn
'FoomaticRIPCommandLine\|FoomaticRIPCommandLinePDF\|FoomaticRIPOptionSetting'
/etc/cups/ppd
/etc/cups/ppd/ricoh.ppd:52:*FoomaticRIPCommandLine: "printf
"%%!PS-Adobe-3.0
/etc/cups/ppd/ricoh.ppd:759:*RIPostScript IRIPS/PostScript Emulation:
"%% FoomaticRIPOptionSetting: RIPostScript=IRIPS"
/etc/cups/ppd/ricoh.ppd:760:*FoomaticRIPOptionSetting
RIPostScript=IRIPS: "/isGenuine{\n&&
...
</pre>
In the example, the print queue called `ricoh` uses the affected PPD options.
If its values are not allowed, the following situation will happen:
<pre>
$ lp -d ricoh /etc/fstab
$ journalctl -u cups -r
...
Job stopped due to filter errors; please consult the syslog file for details.
...
</pre>
If CUPS debug logs are enabled, there is a specific message in the journal:
<pre>
$ journalctl -u cups -r
...
Process is dying with \"ERROR: The value of the key
FoomaticRIPCommandLine is not among the allowed values - see
foomatic-rip man page for more instructions.
...
</pre>
User is expected to run `foomatic-hash`, to review the scan result in
`file_to_review`, and if the found values do not look malicious or the
user accepts them, to copy them into the directory
`/etc/foomatic/hashes.d`:
<pre>
$ sudo foomatic-hash --ppd-paths /etc/cups/ppd file_to_review local_hashes
$ sudo cp local_hashes /etc/foomatic/hashes.h
$ lp -d ricoh /etc/fstab
(Print job succeeds)
</pre>
== User Experience ==
Users with new Fedora 43 installations will have to allow FoomaticRip
values their drivers use after printer installation.
Steps:
<pre>
$ sudo foomatic-hash --ppd-paths /etc/cups/ppd file_to_review local_hashes
$ sudo cp local_hashes /etc/foomatic/hashes.h
</pre>
Users who upgrade to Fedora 43 are expected to review the found values
from their installed printers after upgrade - the file with findings
will be present in the directory `/var/tmp` in the file with prefix
`foomatic-scan`.
In case a malicious or a suspicious value is found, users can find the
driver with the value in the directory `/etc/cups/ppd`. There the
driver file is called `<printer_name>.ppd`, where `<printer_name>` is
the name of a specific printer user has installed. Users are
encouraged to reinstall the printer with a different compatible driver
or delete such printer.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) The upstream
patch won't be applied in cups-filters
* Contingency deadline: Beta Freeze
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
`Foomatic-Rip` filter rejects values of PPD options
`FoomaticRipCommandLine`, `FoomaticRipCommandLinePDF`, and
`FoomaticRipOptionSetting` which are not allowed in configuration on
new Fedora installations by default. Users are expected to run the
tool `foomatic-hash`, review its findings and if they approve the
findings are not malicious, allow the values by moving the file with
hashes into `/etc/foomatic/hashes.d`. See `man foomatic-rip` and `man
foomatic-hash` for more info.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Hi folks,
Just a reminder that today is the deadline to submit your self-contained
changes for Fedora Linux 43. Changes submitted after today will not be
eligible for F43, and instead will be re-targeted to F44.
For existing F43 approved changes, please note that your change is required
to be testable[1] before August 12, 2025.
If you are a maintainer of a Spin or Lab, please reply to the Keepalive
request filed in the schedule repo[2].
For more key dates for F43 and F44, please refer to their respective
schedules[3][4].
I'm out of the office on a family matter today, so all changes awaiting
announcements and processing will be seen to tomorrow, along with
publishing the F45 -F47 schedules.
Kind regards,
Aoife
[1]
https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_ch…
[2] https://www.pagure.io/fedora-pgm/schedule/issues
[3] https://fedorapeople.org/groups/schedule/f-43/f-43-key-tasks.html
[4] https://fedorapeople.org/groups/schedule/f-44/f-44-key-tasks.html
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/PostgreSQL_18
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-postgresql-18-se…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Update of default PostgreSQL stream (`postgresql` and `libpq`
components) in Fedora from version 16 to version 18. This continues
the versioned packaging structure introduced in Fedora 40.
== Owner ==
* Name: [[User:ndavidov| Nikola Davidová]]
* Email: ndavidov(a)redhat.com
== Detailed Description ==
Following the Fedora 40+ PostgreSQL packaging model, each major
version of PostgreSQL is delivered as a separate SRPM. The default
PostgreSQL stream is selected by naming the packages as postgresql,
postgresql-server, etc., while non-default versions use versioned
names like postgresql17.
For Fedora 43, the PostgreSQL 18 SRPM will provide the default
PostgreSQL implementation. The following mapping will apply:
postgresql SRPM -> deprecated
postgresql16 SRPM -> postgresql16, postgresql16-server, ...<br>
postgresql17 SRPM -> postgresql17, postgresql17-server, ...<br>
postgresql18 SRPM -> postgresql, postgresql-server, ...<br>
This also involves updating and rebuilding the PostgreSQL plugins that
depend on postgresql server.
== Feedback ==
== Benefit to Fedora ==
The latest stable software is provided for Fedora users.
== Scope ==
* Proposal owners:
<!-- What work do the feature owners have to accomplish to complete
the feature in time for release? Is it a large change affecting many
parts of the distribution or is it a very isolated change? What are
those changes?-->
**Prepare PostgreSQL 18 as the default stream
**Prepare PostgreSQL 16 as a non-default stream
**Check software that requires or depends on `postgresql-server` or
`libpq` packages for incompatibilities
**Build PostgreSQL 18 (postgresql and libpq) for Rawhide
**Build PostgreSQL 16 for Rawhide
**Rebuild dependent packages against PostgreSQL 18
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Fedora Strategy:
== Upgrade/compatibility impact ==
The PostgreSQL client library (libpq component) is compatible. So,
there shouldn't be any compatibility issues, but rebuild of the
dependent components is recommended.
Server plugins might require a newer version update because they
sometimes have explicit server requirements.
== How To Test ==
All PG server plugins should be installable.
`postgresql-setup --upgrade` command should succeed.
Test that all other software runs well with PostgreSQL 18.
== User Experience ==
The users will have to upgrade their databases the same way as between
major PostgreSQL versions, aka `postgresql-setup --upgrade` after
installing PostgreSQL 18 server packages.
If users want to stick with PostgreSQL 16 for a little longer, there
will be PostgreSQL 16 as nondefault PostgreSQL stream
== Dependencies ==
There are some packages (mostly server plugins), that build on top of
PostgreSQL. Since the separation of PostgreSQL client library (libpq
component), only packages that build server plugins should use
postgresql package in BuildRequires. Others should use libpq. In the
case of Postgresql-server, a rebuild should be done to ensure all
potential binary incompatibilities are handled.
* PostgreSQL server dependecies
** perl-DBD-Pg
** pgaudit
** qt
** qt3
** qt5-qtbase
** postgres-decoderbufs
** gambas3
** kdb
** kea
** libpqxx
** openvas-manager
** orafce
** pg-semver
** pgRouting
** pgadmin3
** pgsphere
** postgis
** postgresql-ip4r
** postgresql-pgpool-II
** qt3
** rdkit
** rhdb-utils
** timescaledb
** pg_repack
== Contingency Plan ==
* Contingency mechanism: 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)
Revert the changes and provide PostgreSQL 16 only.
== Documentation ==
Upgrade strategy: https://www.postgresql.org/docs/18/upgrading.html
N/A (not a System Wide Change)
== Release Notes ==
Release notes for PostgreSQL 18 release:
https://www.postgresql.org/docs/18/index.html
Overall overview of the changes and improvements:
https://www.postgresql.org/docs/18/release-18.html
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/NodejsAlternativesSystem
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-use-update-alter…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
We aim to move away from manual management of
<code>/usr/bin/node</code>, <code>/usr/bin/npm</code>, and similar
symlinks to leveraging update-alternatives system.
== Owners ==
* Name: [[User:aradchen|Andrei Radchenko]]
* Email: aradchen(a)redhat.com
* Name: [[User:jstanek|Jan Stanek]]
* Email: jstanek(a)redhat.com
* Name: [[User:tjuhasz|Tomas Juhasz]]
* Email: tjuhasz(a)redhat.com
== Detailed Description ==
This is a part of a larger iteration in a way we package NodeJS for
Fedora and RHEL. The other parts are [[Changes/NodejsNodeModulesPath]]
and [[Changes/NodeJSMetapackages]].
This change deals specifically with the management of the
non-versioned symlinks in system paths.
Currently, the NodeJS packages (streams) provided in Fedora are all
installable in parallel,
by virtue of moving any potentially conflicting bits into versioned
equivalents and/or versioned directories.
For one example of many:
<pre>
%install
mv %{buildroot}%{_bindir}/node %{buildroot}%{_bindir}/node-%{node_version_major}
...
</pre>
One of the streams is designed as the "default" one, and that stream
then ships manually created non-versioned symlinks to the renamed
paths:
<pre>
%if 0%{nodejs_is_default}
ln -srf %{buildroot}%{_bindir}/node-%{node_version_major}
%{buildroot}%{_bindir}/node
...
%endif
</pre>
By using update-alternatives, we can iterate on this idea and gain
several benefits outlined below.
== Feedback ==
== Benefit to Fedora ==
# No matter which stream you install, you'll always have
<code>/usr/bin/node</code> and other non-versioned names available.
The versioned names will be also present, if you want to be specific
in your scripts.
# There is no "official Fedora endorsement" on which NodeJS stream
should be "best" or "default"; if you as a system administrator have
multiple streams installed, the decision of which should be the
default is up to you.
The second item will also give us the maintainers greater freedom in
introducing new streams and obsoleting the old ones without worrying
too much about how to switch the "default" in the middle of the
distribution life cycle.
This is not a big pain point for Fedora, where the length of the life
of a single version matches the length of upstream NodeJS LTO support
pretty closely,
but becomes much more important in longer-living downstream
distributions (e.g. RHEL).
== Scope ==
* Proposal owners:
** Port the manual symlink creation and management to update-alternatives.
** Ensure the streams behave consistently and no conflict is introduced.
== User Experience ==
* Users will be able to install any number of streams and switch
between default one rather easy by just running `update-alternatives
--config node'.
== Dependencies ==
* Should not cause any problems to dependant packages.
== Contingency Plan ==
* Contingency mechanism: Revert back to manual symlink management and
go back to the design phase.
* Contingency deadline: Beta Freeze.
* Blocks release? We aim to do the rebuilds in Koji side tag and merge
it atomically; so NO.
== Documentation ==
* This is a downstream change; this page is the initial documentation.
* [https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
Fedora Alternatives]
== Release Notes ==
TODO
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/BuildFCOSUsingContainerfile
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-build-fedora-cor…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Define Fedora CoreOS as a `Containerfile` and build it using `podman
build`. The `Containerfile` will build `FROM` the Fedora bootc image.
== Owners ==
* Name/Email: [[User:jlebon|Jonathan Lebon]], jonathan(a)jlebon.com
* Name/Email: [[User:jbtrystram|JB Trystram]], jbtrystram(a)redhat.com
== Detailed Description ==
Currently, Fedora CoreOS (FCOS) is built using `rpm-ostree compose
tree` to build an OSTree commit which is then converted into an OCI
image.
The goal of this enhancement is to switch FCOS to be built via a
Containerfile instead.
=== Relationship to Fedora bootc ===
FCOS is already today sharing manifest definitions with Fedora bootc
via a git submodule. This change will make FCOS instead more
explicitly build `FROM` the Fedora bootc image using the
[https://docs.fedoraproject.org/en-US/bootc/building-from-scratch/
"from scratch" flow]. One can think of this change then as switching
from Fedora bootc and FCOS being siblings, to FCOS becoming a child of
Fedora bootc.
== Feedback ==
== Benefit to Fedora ==
This makes the FCOS build process become a standard container image
build, as advocated by the Fedora bootc project. Currently, building
FCOS requires using a custom tool,
[https://github.com/coreos/coreos-assembler CoreOS Assembler]. With
this change, anyone with `podman` installed would be able to build
FCOS. This in turn means that it's easier for both users and pipelines
to build it. A concrete example is our future plans to build FCOS in
the Fedora Konflux instance.
== Scope ==
* Proposal owners: describe FCOS as a Containerfile, adapt tooling and
pipelines support building FCOS via this Containerfile.
* Other developers: Hopefully nothing!
* Release engineering: Hopefully nothing!
* Alignment with the Fedora Strategy: yes, this falls under the
"Technical Innovation" theme, which lists Image Mode as a Focus Area.
== Upgrade/compatibility impact ==
Ideally none. The goal is to have no end user-visible changes. Fedora
CoreOS content will not meaningfully change.
== How To Test ==
Once ready, booting or updating to an FCOS built via Containerfile.
== User Experience ==
This change should not be visible to end users.
== Contingency Plan ==
* Contingency mechanism: Proposal owners will keep building FCOS using
the current approach (calling `rpm-ostree compose tree` directly).
Note that the way this is implemented, _both_ approaches will be
supported simultaneously as we work on rolling out this change in our
build processes.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
Main discussion in https://github.com/coreos/fedora-coreos-tracker/issues/1861.
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/AutomaticBootloaderUpdatesBootc
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-enable-automatic…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
We will enable automatic updates of the bootloader (GRUB) and shim for
Bootable Container systems (bootc base images, Fedora CoreOS).
== Owner ==
* Name/Email: [[User:hhei| Huijing Hei]], hhei(a)fedoraproject.org
* Name/Email: [[User:Siosm| Timothée Ravier]], siosm(a)fedoraproject.org
* Name/Email: [[User:Walters| Colin Walters]], walters(a)fedoraproject.org
== Detailed Description ==
Currently, Bootable Container systems (bootc base images, Fedora
CoreOS) do not perform bootloader updates automatically during OS
upgrades. This means the GRUB and shim binaries on disk may become
outdated even after a user performs an upgrade. Instead, the user is
responsible for manually updating the bootloader using `bootupctl
update` or `systemctl start bootloader-update.service`.
With this change, users do not need to manually update the bootloader
- it is handled automatically after upgrades. When a new deployment is
created (e.g., via `bootc update` or `rpm-ostree upgrade`), and if the
new image contains updated bootloader artifacts (shim, grub, etc.), a
systemd unit (`bootloader-update.service`) runs on the next boot to
apply the update.
This feature has been enabled by default at boot for both UEFI and
BIOS systems on Fedora Atomic Desktops starting since Fedora 41. For
details, see the approved change proposal:
[https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd
FedoraSilverblueBootupd], and the configuration in
[https://pagure.io/workstation-ostree-config/blob/f41/f/bootupd.yaml
bootupd.yaml].
While bootupd updates are generally safe across both UEFI and BIOS
systems, UEFI is the modern and preferred boot mechanism. On UEFI
systems, the `EFI System Partition (ESP)` is updated safely using a
temporary directory and an atomic `RENAME_EXCHANGE` operation, as
implemented in PR [https://github.com/coreos/bootupd/pull/669 #669]
and discussed in issue [https://github.com/coreos/bootupd/issues/454
#454].
BIOS (MBR) updates are also supported and have been reliable in
practice, but they lack the atomic guarantees and robustness of UEFI.
For this reason, UEFI is recommended for systems that rely on
automatic bootloader updates.
See more discussions in issue
[https://github.com/coreos/fedora-coreos-tracker/issues/1468 #1468]
and [https://github.com/coreos/bootupd#status bootupd's README] for
details about the safety of updates.
== Feedback ==
None so far.
== Benefit to Fedora ==
Bootloader updates generally bring security and other fixes. Applying
them automatically will make sure that all systems are running the
latest versions without any special intervention from users/admins.
== Scope ==
* Proposal owners: Enable automatic bootloader updates for Bootable
Container systems
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: N/A
== Upgrade/compatibility impact ==
Existing installations will have their bootloader updated as part of
this change. This change should not require any manual action.
Users that do not want to have their bootloaders updated automatically
for any reason can mask the systemd unit before the Fedora 43 release
to disable this functionality.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
* Download an older Fedora CoreOS version, and start it.
* Enable `bootloader-update.service`.
* Let the system update to the lastest version automatically via Zincati.
* Once rebooted, verify that the bootloader components have been
updated automatically using bootupd:
<pre>
$ sudo systemctl status bootloader-update.service
$ journalctl -u bootloader-update.service
$ sudo bootupctl status
</pre>
== User Experience ==
Bootloader updates will be automatically applied in the background on
boot. There are no user actions required. User can check the status of
their bootloader with the `bootupctl status` command.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Revert the change
* Contingency deadline: Beta/Final freeze
* Blocks release? No
== Documentation ==
Mostly already written on the bootc and CoreOS side, will need some
small updates:
* https://docs.fedoraproject.org/en-US/bootc/bootloader-updates/
* https://docs.fedoraproject.org/en-US/fedora-coreos/bootloader-updates/
== Release Notes ==
To be written
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/NodejsNodeModulesPath
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-nodejs-node-modu…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Nodejs needs a new shared stream agnostic installation folder for modules.
== Owner ==
* Name: [[User:tjuhasz| Tomas Juhasz]]
* Email: tjuhasz(a)redhat.com
* Name: [[User:jstanek| Jan Stanek]]
* Email: jstanek(a)redhat.com
* Name: [[User:aradchen| Andrei Radchenko]]
* Email: aradchen(a)redhat.com
== Detailed Description ==
This proposal is a part of a larger effort to improve the way we
package Nodejs for Fedora and RHEL. The other parts are
[[Changes/NodejsAlternativesSystem]] and
[[Changes/NodeJSMetapackages]].
This effort is specifically focused on allowing users to install
'''any supported''' version of Nodejs, without specifying a major
version.
=== Current Nodejs Situation ===
Currently, Fedora's Node.js setup uses a symlink:
`%{_libdir}/node_modules` points to a version-specific folder like
`%{_libdir}/node_modulesXX` (e.g., `%{_libdir}/node_modules20` or
`%{_libdir}/node_modules22`).
Primary motivation for change is an ongoing effort to de-bundle
certain parts of Node.js, particularly NPM packages that include
pre-built WebAssembly (WASM) binary blobs.
With multiple Nodejs versions present in Fedora, and upstream
recommendations against globally shared NPM packages in consideration,
we need a better way to store these de-bundled packages which could be
shared between multiple streams.
=== Suggested Change ===
Proposed way of doing this is to change `%{_libdir}/node_modules` from
a symlink to a static shared folder.
This static `%{_libdir}/node_modules` path will be used for
version-agnostic modules that can be shared across multiple Nodejs
versions.
For version-specific dependencies, the existing
`%{_libdir}/node_modulesXX` folders (e.g.,
`%{_libdir}/node_modules20`, `%{_libdir}/node_modules22`) will
continue to be used.
=== Alternative path options ===
If the change of `%{_libdir}/node_modules` from a symlink to a shared
folder is not agreeable a alternative path could also be used for the
same purpose e.g.:
* <code>%{_libdir}/nodejs/packages/shared</code> for NPM packages that
can be shared between multiple NodeJS major versions. This should be
the default path for the unbundled packages unless a stream is
identified to need a specific version.
* <code>%{_libdir}/nodejs/packages/<major_version></code> for NPM
packages that are specifically used by a single NodeJS major version.
Reserved for compat-style packages.
Packages installed in these paths are assumed to be used by a
non-npm-related loading mechanism; for NodeJS specifically, via the
"Shared builtins" mechanism
([https://github.com/nodejs/node/blob/main/BUILDING.md#building-to-use-shared…
upstream docs]).
== Feedback ==
== Benefit to Fedora ==
By having downstream-standartized path for "Shared builtins" modules,
we can start removing potentially unsafe pre-build WASM (binary) blobs
from the NodeJS sources, rebuilding them on our infrastructure from
trusted sources.
Accommodating single default shared directory will reduce work
necessary for unbundling the packages from several NodeJS major
versions at once, while the preservation of version-specific paths
will allow for compatibility packages where necessary.
== Scope ==
* Proposal owners: Adding a small `%pretrans` scriptlet for turning
`/usr/lib/node_modules` into a separate directory in all active nodejs
streams
* Other developers: Any developers who package npm packages will need
to verify, that their RPM will be functional after the
`%{_libdir}/node_modules` will change from a symlink to a folder and
if necessary rebuild their packages so that the files are present in
`%{_libdir}/node_modules` and rather then in e.g.
`%{_libdir}/node_modules_22`.
* Release engineering: N/A
* Policies and guidelines: N/A.
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
There should be no need for manual intervention.
== Early Testing (Optional) ==
== How To Test ==
Allow to install nodejs dependencies like `nodejs-cjs-module-lexer`
into a shared static folder.
== User Experience ==
User experience should not be affected in any way.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: Reverting the change back to using
`%{_libdir}/node_modules` as a symlink pointing to version specific
folders.
* Contingency deadline: N/A
* Block release: N/A
== Documentation ==
This Page.
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney