Wiki: https://fedoraproject.org/wiki/Changes/Nix_package_tool
Discussion Thread: https://discussion.fedoraproject.org/t/170391
**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 ==
Add the [https://github.com/NixOS/nix/ nix] functional package manager
developer tool to Fedora.
== Owner ==
* Name: [[User:Petersen| Jens Petersen]]
* Email: <petersen(a)redhat.com>
* Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: <zbyszek(a)in.waw.pl>
== Detailed Description ==
Nix is a cross-platform package manager for Unix-like systems with its own
package ecosystem.
It is also the package manager for the NixOS Linux operating system.
The nix package tool provides access to the [
https://github.com/NixOS/nixpkgs nixpkgs] ecosystem with over 100,000 [
https://search.nixos.org/packages packages].
Packages and environments can be specified in nix's declarative functional
programming language using so-called derivations. Nix [
https://wiki.nixos.org/wiki/Flakes flakes] provide a newer way to specify
these project development environments.
Nix has two main modes of installation/setup: multi-user mode (with
nix-daemon) and single-user mode
(below these are abbreviated as "multiuser" and "singleuser" respectively).
The Fedora package tries to support both of them, though multiuser mode
setup where available is more seamless. It does this by providing
`nix-daemon` and `nix-system` subpackages which both require
`nix-filesystem`. The `/nix` toplevel directory is defined with tmpfiles.d
and can be a Btrfs subvolume if setup.
== Feedback ==
== Benefit to Fedora ==
Some developers and upstream projects now prefer or use nix for development
and reproducible build environments.
Just as we have apt packaged in Fedora, this change adds a nix package
allowing access to its ecosystem from Fedora.
With the implementation of this Change, Fedora users will be able to
install nix easily on their system and leverage it in development projects
that may require nix. They will also be able to easily try out some of the
many packages in nixpkgs for testing or experimenting, etc.
For some time I have maintained a nix [
https://copr.fedorainfracloud.org/coprs/petersen/nix/ copr repo] which is
quite popular (see the download numbers and note a number of other nix copr
repos also exist), but it will be easier for Fedora users to have the nix
package directly available from Fedora repos.
== Scope ==
* Proposal owners:
** prepare the [https://src.fedoraproject.org/rpms/nix package] of nix
version 2.31 or later [[https://bugzilla.redhat.com/show_bug.cgi?id=2388768
pkgreview]]
* Policies and guidelines:
** We have received an [https://pagure.io/fesco/issue/3473 exception
approval] from FESCO to allow the nix package to use /nix toplevel
directory at runtime, as it is needed to make full use of nixpkgs and
cachix binaries, etc.
** The approved exception still needs to be documented
** To be clear: nix and its subpackages will remain optional development
packages that Fedora users can install manually if they wish, and in
particular /nix is not to be used for Fedora Linux development.
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
== How To Test ==
Copr builds are available from
https://copr.fedorainfracloud.org/coprs/petersen/nix/.
Installation/setup:
Either:
* Multiuser daemon mode:
** `sudo dnf install nix`
** `sudo systemctl enable --now nix-daemon`
or
* Singleuser mode
** `sudo dnf install nix --exclude nix-daemon`
** `sudo usermod -G nixbld -a $USER`
See also `/usr/share/doc/nix/README.fedora.md` or
https://src.fedoraproject.org/rpms/nix.
Then try out the tool:
* `nix-shell -p hello`
* try the `*.nix` examples in
https://src.fedoraproject.org/rpms/nix/blob/rawhide/f/examples
* `nix search nixpkgs <package-regexp>`
* try online documentation examples or projects
Notes:
* Upstream recommends using the nix-daemon and multiuser mode.
* However `/nix` is incompatible with ostree (it can probably be used in
bootc Image Mode): so on ostree systems one should use it within a toolbox
instead.
* Since containers and toolbox normally do not have functioning systemd: it
is not possible to use nix-daemon inside containers by default
** instead install the nix-singleuser subpackage
* Be warned that nix can easily use up ''large amounts of diskspace''. You
can use `nix-collect-garbage` to clean up or clear `/nix/store/`. In the
worst case it should be safe to remove `rm -r /nix/store/*` completely. The
`/nix` tree can also safely be removed after uninstalling nix.
* Please use nix and nixpkgs etc at your own risk, as you would other
upstream package ecosystems.
== User Experience ==
Fedora users can now seamlessly install and use the Nix package manager for
development or running its packages locally on their system.
== Dependencies ==
There are no blocking dependencies. However:
* newer boost library would allow shipping latest nix 2.32 [in progress]
* mdbook (rust-based documentation tool) would probably allow building the
documentation (and manpages) [under review]
== Contingency Plan ==
== Documentation ==
See https://nix.dev/reference/nix-manual.html.
== Release Notes ==
* The Nix package manager developer tool has been packaged in Fedora for
users.
Hi all,
Today is my last day around the Fedora Project for a while. I will be back
though! You can't get rid of me that easily ;-) I will be on maternity
leave from Monday, 27 October 2025 and will return to middle earth on
Monday, 18 May 2026.
In my absence, I have recruited a little fellowship to cover tasks of the
FOA role. The FOA page[1] on Fedora Docs has been updated with details on
who will be covering what, and should be rebuilt shortly to reflect the
changes.
There is also an F47 and F48 release schedules[2][3] published as well for
all of you very early birds to file change proposals against :)
A few important notes:
1. Changes Processing
Allison King is your F44 (and parts of F45) Change Wrangler. Allison was
introduced a few months ago to you all[4], and for full transparency and as
a reminder, we have been using Claude CLI for automating the process. It is
a local service and not part of Fedora infra. Changes that Claude processes
are always checked by Allison and I for correctness when they are
announced, submitted for FESCo vote and processed. Allison will continue to
use Claude to assist in the processing for F44 Changes, as she and I have
been doing for the last few weeks.
2. Schedule Management
Jef, our FPL, is taking on the schedule management part of the job in a
limited capacity. This means that the only schedule changes will be for
Fedora Linux 44. These changes will be restricted to release date changes
if target dates are missed, or critical schedule amendments that FESCo
requires. Please file all schedule change requests in the schedule repo[5].
[1] https://docs.fedoraproject.org/en-US/council/foa/
[2] https://fedorapeople.org/groups/schedule/f-47/f-47-key-tasks.html
[3] https://fedorapeople.org/groups/schedule/f-48/f-48-key-tasks.html
[4]
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…
[5] https://pagure.io/fedora-pgm/schedule
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki:
https://fedoraproject.org/wiki/Changes/Enforcing_signature_checking_by_defa…
Discussion Thread: https://discussion.fedoraproject.org/t/169774
**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 ==
Change the RPM default package verification mode to enforcing signature
checking, to follow upstream RPM 6.0 default:
only packages with a verified signature can be installed, unless explicitly
overridden by `--nosignature` or corresponding API.
== Owner ==
* Name: [[User:pmatilai| Panu Matilainen]]
* Email: pmatilai(a)redhat.com
== Detailed Description ==
On RPM level, this is a one-line configuration change: `%_pkgverify_level`
default is changed from `digest` to `all`, which
requires packages to have both a verified signature(s) and digest(s) to be
installable. This means `rpmkeys -K/--checksig` will fail on unsigned
packages, and `rpm` will refuse to install such packages, unless explicitly
overridden with `--nosignature` (or corresponding API).
This change was originally intended to happen as a side-effect of
https://fedoraproject.org/wiki/Changes/RPM-6.0
but was postponed to Fedora 44 due to time and resource reasons.
DNF5 >= 5.2.14.0 (in Fedora >= 42) has the necessary integration to allow
disabling the verification on per-package
basis to support repositories with disabled signature checking. This is
used by mock to handle newly
built, unsigned packages, and continues to work without further changes.
Mock has a plugin for signing locally built packages, and COPR has it's own
automatic signing.
For packages locally built with rpmbuild, RPM >= 6.0 supports automatic
signing by a passwordless key to make local `rpmbuild`
use almost as seamless as before, and comes with a easy one-time setup
script: `/usr/lib/rpm/rpm-setup-autosign`.
== Feedback ==
== Benefit to Fedora ==
The traditional RPM <= 4.x behavior was to verify a signatures if they are
present and verifiable, but never require it. That behavior may have
been somehow acceptable in the nineties, but does not meet the security
expectations of modern times. Besides being insecure, the semantics
cause quirky and non-obvious behavior in various situations.
Higher level package managers like yum and dnf/dnf5 have implemented their
own enforcing signature modes, enabled by default
since the beginning of Fedora. This change brings the RPM side default
behavior to this millenium.
== Scope ==
* Proposal owners:
** Change the RPM configuration.
** Assist with with adoption as necessary, and address possible unforeseen
/ newly found issues in rpm/dnf/mock
* Other developers:
** Adjust their local package building workflows to either use signed
packages or explicitly disable the signature checking where necessary (see
compatibility impact).
* Release engineering: [https://pagure.io/releng/issues/13027 #13027]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: Improved security should align with
Fedora strategy, whether written down or not.
== Upgrade/compatibility impact ==
There's no impact on the average system only utilizing packages from
official or 3rd party repositories.
Dnf, mock, the official Fedora buildsystem and COPR should be fully
compatible with this change as-is.
However, this change will almost certainly require some changes to
rpm/rpmbuild related workflows that the RPM team hasn't even heard of.
In some cases it might be sufficient to import relevant keys before
operating on packages. Ideally, workflows involving unsigned packages are
updated to use signed packages. Where that is not immediately or easily
feasible, explicit `--nosignature` (or corresponding API)
switches or local configuration change to a more permissive policy may need
to be added to scripts / system configuration.
Changes might be needed if there are local rpmbuild-related workflows, see
Scope.
== How To Test ==
This will receive thorough testing in everyday system use through system
updates and on the buildsystem side, building packages. Specific items to
test locally include:
* Try to install or verify an unsigned package (must fail)
* Try to install or verify a signed package whose key is not imported (must
fail)
* Try to install or verify both of the above with `--nosignature` (should
succeed if legit package)
* Test automatic signing in rpmbuild:
** Run `/usr/lib/rpm/rpm-setup-autosign`
** Import the key as indicated by rpm-setup-autosign output
** Build some package(s)
** Try to install those packages (must not fail due to signature)
== User Experience ==
* Packages without verifiable signature(s) cannot be installed without an
explicit override.
== Dependencies ==
* dnf, mock, koji, copr are related but the buildsystem(s) are expected to
work with no further changes
* there may be unforeseen / unknown dependencies in the infrastructure
* `dnf --no-gpgchecks` needs [
https://github.com/rpm-software-management/dnf5/issues/2479 integration]
== Contingency Plan ==
* Contingency mechanism: Revert back to digest verification by default for
F44 and try again in F45.
* Contingency deadline: beta freeze
* Blocks release? Yes
== Documentation ==
The package verification policy configurables (`%_pkgverify_*`) are
documented in the
[https://rpm.org/docs/6.0.x/man/rpm-config.5 rpm-config(5)] manual.
== Release Notes ==
Wiki:
https://fedoraproject.org/wiki/Changes/Adopt_new_R_Packaging_Guidelines
Discussion Thread: https://discussion.fedoraproject.org/t/169773
**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 ==
There are currently over 400 R packages in Fedora's repositories, many of
them with slightly different interpretations of the [
https://docs.fedoraproject.org/en-US/packaging-guidelines/R/ R Packaging
Guidelines], which contain almost no automations. As a result, different
packages implement different techniques for dealing with the various quirks
derived from such guidelines. With this proposal, we aim at automation,
reliability and simplicity via [
https://github.com/rpm-software-management/R-rpm-macros/pull/2 newly
developed RPM macros], placing R packaging on the same level as other
software stacks.
== Owner ==
* Name: [[User:iucar| Iñaki Úcar]]
* Email: r-maint-sig(a)lists.fedoraproject.org
== Detailed Description ==
This proposal consists of:
* Updating `R-rpm-macros` with [
https://github.com/rpm-software-management/R-rpm-macros/pull/2 new macros].
* Adding `R-srpm-macros` to the default buildroot via Requires in
`redhat-rpm-config`.
* Getting [https://fedoraproject.org/wiki/PackagingDrafts/R new R Packaging
Guidelines] based on these macros approved by the FPC.
* Updating the [https://pagure.io/r2spec R2spec] tool to follow the new
guidelines.
* Updating all R packages with the new guidelines.
* Mass-rebuilding all R packages in a side tag.
== Feedback ==
Some early feedback was gathered from [
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
this devel thread], and then implemented in the current proposal:
* Avoid requiring packagers to set global variables.
* Try to keep name and version static.
* Avoid ''automagic''-type macros that add lines to the preamble and
calculates other macros for later use (i.e. the `%foometa` approach).
== Benefit to Fedora ==
* Simplicity: with a drastic reduction of boilerplate, spec files are
simpler, less error-prone.
* Automation: the new macros
** take care of version normalization, and compute project and source URLs;
** have provisions for [[Changes/DynamicBuildRequires]];
** automate installation, checks and file generation.
* Standardization of spec files across the R library.
== Scope ==
* Proposal owners: see detailed description above.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: update R Packaging Guidelines and get them
approved by the FPC.
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
No compatibility impact is expected.
== How To Test ==
The [https://copr.fedorainfracloud.org/coprs/iucar/R/ iucar/R] Copr repo
can be used to test the new macros on rawhide. A sample spec file is
available in the [https://fedoraproject.org/wiki/PackagingDrafts/R
guidelines proposal].
== User Experience ==
See the [https://fedoraproject.org/wiki/PackagingDrafts/R proposed R
Packaging Guidelines]. As a result of the simplification of spec files, we
may ship updated libraries more quickly, and it may be easier for new
contributors to package R packages.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
N/A
Hello folks,
as you might now, there is a proposal for a new *Fedora AI-Assisted
Contributions Policy* which the Councils hould vote on soon.
Since the first proposal, it has evolved based on your feedback.
Here is what we are about to vote on:
*Fedora AI-Assisted Contributions Policy*
=========================================
1. You *MAY* use AI assistance for contributing to Fedora, as long as you
follow the principles described below.
2. *Accountability:* You *MUST* take the responsibility for your contribution:
Contributing to Fedora means vouching for the quality, license compliance, and
utility of your submission. All contributions, whether from a human author or
assisted by large language models (LLMs) or other generative AI tools, must
meet the project's standards for inclusion. The contributor is always the
author and is fully accountable for their contributions.
3. *Transparency:* You *MUST* disclose the use of AI tools when the
significant part of the contribution is taken from a tool without changes. You
*SHOULD* disclose the other uses of AI tools, where it might be useful. Routine
use of assistive tools for correcting grammar and spelling, or for clarifying
language, does not require disclosure.
Information about the use of AI tools will help us evaluate their impact,
build new best practices and adjust existing processes.
Disclosures are made where authorship is normally indicated. For
contributions tracked in git, the recommended method is an `Assisted-by:`
commit message trailer. For other contributions, disclosure may include
document preambles, design file metadata, or translation notes.
Examples:
Assisted-by: generic LLM chatbot
Assisted-by: ChatGPTv
4. *Contribution & Community Evaluation:* AI tools may be used to assist human
reviewers by providing analysis and suggestions. You MUST NOT use AI as the
sole or final arbiter in making a substantive or subjective judgment on a
contribution, nor may it be used to evaluate a person's standing within the
community (e.g., for funding, leadership roles, or Code of Conduct matters).
This does not prohibit the use of automated tooling for objective technical
validation, such as CI/CD pipelines, automated testing, or spam filtering. The
final accountability for accepting a contribution, even if implemented by an
automated system, always rests with the human contributor who authorizes the
action.
5. *Large scale initiatives:* The policy doesn't cover the large scale
initiatives which may significantly change the ways the project operates or
lead to exponential growth in contributions in some parts of the project. Such
initiatives need to be discussed separately with the Fedora Council.
Concerns about possible policy violations should be reported via private
tickets to Fedora Council(link).
The key words "MAY", "MUST", "MUST NOT", and "SHOULD" in this document are to
be interpreted as described in *RFC 2119*.
==============================================================================
If you have concerns, please speak up soon in
https://discussion.fedoraproject.org/t/council-policy-proposal-policy-on-ai…
--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok
Wiki: https://fedoraproject.org/wiki/Changes/Python3.15
Discussion Thread: https://discussion.fedoraproject.org/t/169003
**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 the Python stack in Fedora from Python 3.14 to Python 3.15, the
newest major release of the Python programming language.
== Owner ==
* Name: [[User:ksurma| Karolina Surma]]
* Name: [[User:churchyard| Miro Hrončok]]
* Email: python-maint(a)redhat.com
== Detailed Description ==
We would like to upgrade Python to 3.15 in Fedora 45 thus we are proposing
this plan early.
See the upstream notes at [https://docs.python.org/dev/whatsnew/3.15.html
What's new in 3.15].
=== Important dates and plan ===
* 2025-05-07: Python 3.15 development begins
* 2025-10-14: Python 3.15.0 alpha 1
** Package it as {{package|python3.15}} for testing purposes
** Start the bootstrap procedure in Copr
** Do a mass rebuild against every future release in Copr
* 2025-11-18: Python 3.15.0 alpha 2
* 2025-12-16: Python 3.15.0 alpha 3
* 2026-01-13: Python 3.15.0 alpha 4
* 2026-02-03: Branch Fedora 44, Rawhide becomes future Fedora 45
** The earliest point when we can start rebuilding in Koji side-tag
* 2026-02-10: Python 3.15.0 alpha 5
* 2026-03-10: Python 3.15.0 alpha 6
* 2026-04-07: Python 3.15.0 alpha 7
* 2026-05-05: Python 3.15.0 beta 1
** No new features beyond this point
* 2026-05-26: Python 3.15.0 beta 2
** The ideal point when we can start rebuilding in Koji
* 2026-06-02: Expected side tag-merge (optimistic)
* 2026-06-16: Python 3.15.0 beta 3
* 2026-06-23: Expected side tag-merge (realistic)
* 2026-06-30: Expected side tag-merge (pessimistic)
* 2026-07-14: Python 3.15.0 beta 4
* 2026-07-22: Fedora 45 Mass Rebuild
** The mass rebuild happens with the fourth or third beta. We might need to
rebuild Python packages later in exceptional case.
** If the Koji side-tag is not merged yet at this point, we defer the
change to Fedora 46.
* 2026-07-28: Python 3.15.0 candidate 1
** This serves as "final" for our purposes.
* 2026-08-11: Branch Fedora 45, Rawhide becomes future Fedora 46
* 2026-08-11: Fedora 45 Change Checkpoint: Completion deadline (testable)
* 2026-08-25: Fedora Beta Freeze
** If rebuild with 3.15.0rc1 is needed, we should strive to do it before
the freeze - there is a window of 4 weeks.
* 2026-09-01: Python 3.15.0 candidate 2
* 2026-09-15: Fedora 45 Beta Release (Preferred Target)
** Beta will likely be released with 3.15.0rc2.
* 2026-10-01: Python 3.15.0 final
* 2026-10-06: Fedora 45 Final Freeze
** If the 3.15.0 final release is delayed, we'll update it using a freeze
exception.
* 2026-10-20: Fedora 45 Final Target date #1
* 2026-10-27: Fedora 45 Final Target date #2
(From [https://peps.python.org/pep-0790/#release-schedule Python 3.15
Release Schedule] and [
https://fedorapeople.org/groups/schedule/f-45/f-45-key-tasks.html Fedora 45
Release Schedule].)
The schedule might appear somewhat tight for Fedora 45, but Python's [
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
annual release cycle was adapted for Fedora] and this worked fine since
Python 3.9 and Fedora 33. It is now common that Python is upgraded on a
similar schedule in every odd-numbered Fedora release.
Note that upstream's "release candidates" are frozen except for blocker
bugs. Since we can and will backport blocker fixes between Fedora and
upstream, we essentially treat the Release Candidate as the final release.
== Feedback ==
== Benefit to Fedora ==
Fedora aims to showcase the latest in free and open-source software - we
should have the most recent release of Python 3. Packages in Fedora can use
the new features from 3.15.
There's also a benefit to the larger Python ecosystem: by building Fedora's
packages against 3.15 while it's still in development, we can catch
critical bugs before the final 3.15.0 release.
== Scope ==
We will coordinate the work in a side tag and merge when ready.
* Proposal owners:
*# Introduce {{package|python3.15}} for all Fedoras
*# Prepare stuff in Copr as explained in description.
*# Update {{package|python-rpm-macros}} so {{package|python3.15}} builds
{{package|python3}}
*# Build {{package|python3.15}} as the main Python
*# Mass rebuild all the packages that runtime require `python(abi) = 3.14`
and/or `libpython3.14.so.1.0` (~3900 known packages in October 2025)
*# Build {{package|python3.14}} as a non-main Python
* Other developers: Maintainers of packages that fail to rebuild during the
rebuilds will be asked, using e-mail and bugzilla, to fix or remove their
packages from the distribution. If any issues appear, they should be
solvable either by communicating with the respective upstreams first and/or
applying downstream patches. Also, the package maintainers should have a
look at: [https://docs.python.org/dev/whatsnew/3.15.html#id2 Porting to
Python 3.15]. The python-maint team will be available to help with fixing
issues.
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
All the packages that depend on Python 3 must be rebuilt. User written
Python 3 scripts/applications may require a small amount of porting, but
mostly Python 3.14 is forward compatible with Python 3.15.
Packages that fail to install because they failed to rebuild with Python
3.15 will be retired at Final Freeze unless they have a proposed Freeze
Exception.
== Early Testing (Optional) ==
== How To Test ==
Interested testers do not need special hardware. If you have a favorite
Python 3 script, module, or application, please test it with Python 3.15
and verify that it still works as you would expect. If the application you
are testing does not require any other modules, you can test it using
{{package|python3.15}} even before this change is implemented, in Fedora
41, 42, 43 or 44.
In case your application requires other modules, or if you are testing an
rpm package, it is necessary to install the 3.15 version of the python3
rpm. That rpm will shortly be available in Copr, along with all other
python packages that build successfully with python 3.15. See
https://copr.fedorainfracloud.org/coprs/g/python/python3.15/ for detailed
instructions on how to enable Python 3.15 Copr for mock.
Once the change is in place, test if your favorite Python apps are working
as they were before. File bugs if they don't.
== User Experience ==
Regular distro users shouldn't notice any change in system behavior other
than the Python 3 interpreter will be in version 3.15.
== Dependencies ==
~4300 packages depend on Python 3 and ~3900 packages need rebuilding when
Python is upgraded. See scope section.
== Contingency Plan ==
* Contingency mechanism: Do not merge the side tag with rawhide. If the
side tag has been merged and issues arise, that will justify a downgrade,
then use an epoch tag to revert to 3.14 version (never needed before)
== Documentation ==
[https://peps.python.org/pep-0790/ Python 3.15 Release Schedule]
[https://docs.python.org/dev/whatsnew/3.15.html What's new in 3.15]
== Release Notes ==
Wiki: https://fedoraproject.org/wiki/Changes/BtrfsBootForCloud
Discussion Thread: https://discussion.fedoraproject.org/t/169002
**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 ==
Eliminate the separate /boot partition on Fedora Cloud images
== Owner ==
* Name: [[User:ngompa|Neal Gompa]], [[User:davdunc|David Duncan]]
* Email: ngompa13(a)gmail.com, davdunc(a)amazon.com
== Detailed Description ==
The images produced by Fedora Cloud for Cloud platforms and Vagrant will
drop the separate <code>/boot</code> in favor of a Btrfs subvolume. This
will not apply to UEFI-UKI and s390x Cloud images due to limitations of
those platforms.
== Feedback ==
== Benefit to Fedora ==
Fedora Cloud Edition is typically deployed as images of fixed sizes and
grown on deployment, so it is attractive for us to minimize the footprint
of the image up-front. Since Fedora Cloud images do not rely on grubenv
features like the [[Changes/HiddenGrubMenu|GRUB Hidden Menu]] feature
(which requires resolving [https://bugzilla.redhat.com/2372973
rhbz#2372973] first), we can easily consolidate the bootloader data on the
Btrfs volume. By using a Btrfs subvolume, it can be trivially omitted from
any snapshot mechanisms used on the deployment while avoiding space
contention for boot data and the rest of the operating environment data.
== Scope ==
* Proposal owners: Merge [
https://pagure.io/fedora-kiwi-descriptions/pull-request/228
fedora-kiwi-descriptions#228]
* Other developers: N/A
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
There are no compatibility impacts, as this only affects new Cloud
deployments with Fedora 44 or higher.
== How To Test ==
Once the kiwi-descriptions PR is merged, images should be available in the
new configuration. Just boot them in the platform of your choice to test.
== User Experience ==
This should be transparent to users.
== Contingency Plan ==
* Contingency mechanism: Revert the pull request to go back to separate
<code>/boot</code> volume.
* Contingency deadline: Final Freeze
* Blocks release? Yes
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Fedora Cloud images (except the UEFI-UKI images) on all architectures
except IBM Z systems no longer have a separate <code>/boot</code>
partition, and instead now ship <code>/boot</code> as a subvolume in the
main Btrfs operating system volume. This allows for much better space
utilization and smaller images.