https://fedoraproject.org/wiki/Changes/Python3.12
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.11 to Python 3.12, the
newest major release of the Python programming language.
== Owner ==
* Name: [[User:Thrnciar|Tomáš Hrnčiar]]
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: python-maint(a)redhat.com
== Detailed Description ==
We would like to upgrade Python to 3.12 in Fedora 39 thus we are
proposing this plan early.
See the upstream notes at
[https://peps.python.org/pep-0693/#features-for-3-12 Features for
3.12] and [https://docs.python.org/3.12/whatsnew/3.12.html What's new
in 3.12].
=== Important dates and plan ===
* 2022-05-08: Python 3.12 development begins
* 2022-10-24: Python 3.12.0 alpha 1
** Package it as {{package|python3.12}} for testing purposes
** Start the bootstrap procedure in Copr
** Do a mass rebuild against every future release in Copr
* 2022-11-14: Python 3.12.0 alpha 2
* 2022-12-05: Python 3.12.0 alpha 3
* 2023-01-09: Python 3.12.0 alpha 4
* 2023-02-06: Python 3.12.0 alpha 5
* 2023-02-07: Branch Fedora 38, Rawhide becomes future Fedora 39
** The earliest point when we can start rebuilding in Koji side-tag
* 2023-03-06: Python 3.12.0 alpha 6
* 2023-04-03: Python 3.12.0 alpha 7
* 2023-05-08: Python 3.12.0 beta 1
** No new features beyond this point
* 2023-05-29: Python 3.12.0 beta 2
** The ideal point when we can start rebuilding in Koji
* 2023-06-05: Expected side tag-merge (optimistic)
* 2023-06-19: Python 3.12.0 beta 3
* 2023-06-26: Expected side tag-merge (realistic)
* 2023-07-10: Python 3.12.0 beta 4
* 2023-07-17: Expected side tag-merge (pessimistic)
* 2023-07-19: Fedora 39 Mass Rebuild
** The mass rebuild happens with the fourth 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 38.
* 2023-07-31: Python 3.12.0 candidate 1
** This serves as "final" for our purposes.
* 2023-08-08: Branch Fedora 39, Rawhide becomes future Fedora 40
* 2023-08-08: Fedora 39 Change Checkpoint: Completion deadline (testable)
* 2023-08-22: Fedora Beta Freeze
** If rebuild with 3.12.0rc1 is needed, we should strive to do it
before the freeze - there is a window of 3 weeks.
* 2023-09-04: Python 3.12.0 candidate 2
* 2023-09-12: Fedora 39 Beta Release (Preferred Target)
** Beta will likely be released with 3.12.0rc2.
* 2023-09-19: Fedora 39 Beta Target date #1
* 2023-10-02: Python 3.12.0 final
* 2023-10-03: Fedora 39 Final Freeze
** We'll update to 3.12.0 final using a freeze exception.
* 2023-10-17: Fedora 39 Preferred Final Target date
* 2023-10-24: Fedora 39 Final Target date #1
(From [https://peps.python.org/pep-0693/#release-schedule Python 3.12
Release Schedule] and
[https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html
Fedora 39 Release Schedule].)
The schedule might appear somewhat tight for Fedora 39, 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.
=== Notes from the previous upgrade ===
There are notes from the previous upgrade available, so this upgrade
may go smoother: [[SIGs/Python/UpgradingPython]]
== 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.12.
There's also a benefit to the larger Python ecosystem: by building
Fedora's packages against 3.12 while it's still in development, we can
catch critical bugs before the final 3.12.0 release.
== Scope ==
We will coordinate the work in a side tag and merge when ready.
* Proposal owners:
*# Introduce {{package|python3.12}} for all Fedoras
*# Prepare stuff in Copr as explained in description.
*# Update {{package|python-rpm-macros}} so {{package|python3.12}}
builds {{package|python3}}
*# Build {{package|python3.12}} as the main Python
*# Mass rebuild all the packages that runtime require `python(abi) =
3.11` and/or `libpython3.11.so.1.0` (~3900 known packages in October
2022)
*# Build {{package|python3.12}} 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/3.12/whatsnew/3.12.html#porting-to-python-3-12
Porting to Python 3.12]. The python-maint team will be available to
help with fixing issues.
* Release engineering: [TBD]
* Policies and guidelines: nope
* Trademark approval: nope
== 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.11 is forward compatible with Python 3.12.
=== The Python standard library distutils module will be removed ===
For many years distutils module was providing support for building and
installing additional modules into a Python installation.
Since Python 3.10 distutils package is deprecated, and will be removed
in Python 3.12. Its functionality for specifying package builds has
already been completely replaced by third-party packages setuptools
and packaging, and most other commonly used APIs are available
elsewhere in the standard library (such as platform, shutil,
subprocess or sysconfig).
Affected packages will be failing with `ModuleNotFoundError: No module
named 'distutils'`.
The python3-setutpools package provides a distutils module, so
sometimes "simply" adding BuildRequires: python3-setuptools might
workaround the problem. Unfortunately, it is not 100 % compatible with
the removed standard library one distutils:
https://github.com/pypa/setuptools/issues/3532
Fedora packagers can check if their packages build without distutils
by removing it form Python 3.11:
# `fedpkg clone <package name> && cd <package name>`
# `mock -r fedora-rawhide-x86_64 init`
# `mock -r fedora-rawhide-x86_64 install python3-devel`
# `sudo rm -rf /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib64/python3.11/distutils/`
# `fedpkg mockbuild -N`
Later, when [https://copr.fedorainfracloud.org/coprs/g/python/python3.12/
Python 3.12 COPR] is available, you can use it for testing.
See https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproj…
for known Fedora packages that'll need changes.
== How To Test ==
Interested testers do not need special hardware. If you have a
favourite Python 3 script, module, or application, please test it with
Python 3.12 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.12}} even before this change is
implemented, in Fedora 36, 37 or 38.
In case your application requires other modules, or if you are testing
an rpm package, it is necessary to install the 3.12 version of the
python3 rpm. Right now that rpm is available in copr, along with all
other python packages that build successfully with python 3.12. See
https://copr.fedorainfracloud.org/coprs/g/python/python3.12/ for
detailed instructions on how to enable Python 3.12 copr for mock.
Once the change is in place, test if your favourite 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 behaviour
other than the Python 3 interpreter will be in version 3.12.
== Dependencies ==
4000+ 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.11 version (never
needed before) * Contingency deadline: TBD
* Blocks release? Yes, we'd like to block Fedora 39 release on at
least 3.12.0rc1
* Blocks product? See above
== Documentation ==
[https://peps.python.org/pep-0693/ Python 3.12 Release Schedule]
[https://peps.python.org/pep-0693/#features-for-3-12 Features for 3.12]
[https://docs.python.org/3.12/whatsnew/3.12.html What's new in 3.12]
[https://docs.python.org/3.12/whatsnew/3.12.html#porting-to-python-3-12
Porting to Python 3.12]
== Release Notes ==
* Migrating user installed packages -
https://pagure.io/fedora-docs/release-notes/issue/503
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/PortingToModernC.
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 ==
Back in 1999, a new revision of the C standard removed several
backwards compatibility features. However, GCC still accepts these
obsolete constructs by default. Support for these constructs is
confusing to programmers and potentially affect GCC's ability to
implement features from future C standards.
== Owner ==
* Name: [[User:fweimer| Florian Weimer]]
* Email: [mailto:fweimer@redhat.com| fweimer(a)redhat.com]
== Detailed Description ==
The most important change is the <b>removal of implicit function
declarations</b>. This legacy compatibility feature causes the
compiler to automatically supply a declaration of type `int
function()` if `function` is undeclared, but called as a function.
However, the implicit return type of `int` is incompatible with
pointer-returning functions, which can lead to difficult debugging
sessions if the compiler warning is missed, as described here:
* [https://developers.redhat.com/blog/2019/04/22/implicit-function-declaration…
Implicit function declarations: flex's use of "reallocarray"]
On x86-64, functions returning `_Bool` called with an implicit
declaration will also not work correctly because the return register
value for `_Bool` functions is partially undefined (not all 32 bits in
the implicitly declared `int` are defined).
Another change for C99 is the <b>removal of implicit `int` type
declarations</b>. For example, in the following fragment, both `i` and
`j` are defined as `int` variables:
<pre>
static i = 1.0;
auto j = 2.0;
</pre>
Support for this obsolete constructs is incompatible with adoption of
type inference for `auto` definitions (which are part of C++).
Neither change is trivial to implement because introducing errors for
these constructs (as required by C99) alters the result of autoconf
configure checks. Quite a few such checks use an implicitly declared
`exit` function, for instance. These failures are not really related
to the feature under test. If the build system is well written, the
build still succeeds, the relevant features are automatically disabled
in the test suite and removed from reference ABI lists, and it's not
immediately apparent that feature is gone. Therefore, some care is
needed that no such alterations happen, and packages need to be ported
to C99. Various tools for this porting activity are being developed to
support this proposal. Cross-distribution collaboration will help as
well, sharing patches and insights.
GCC 14 may also make other changes by default, as described below.
These changes will also require extensive testing, and some adoption
of configure checks.
==== Removal of old-style function definitions ====
An old style function definition looks like this:
<pre>
int
sum (a, b)
char *a;
int b;
{
return atoi (a) + b;
}
</pre>
It is equivalent to this definition with a prototype:
<pre>
int
sum (char *a, int b)
{
return atoi (a) + b;
}
</pre>
This legacy feature is very close to being incompatible with the C2X
standard, which introduces unnamed function arguments. But due to a
quirk in GCC's implementation, it should be possible to support both
at the same time.
==== New keywords <code>bool</code>, <code>true</code>, <code>false</code> ====
Packages which supply their own definitions instead of including
`<stdbool.h>` (which remains available) might fail to build.
==== Change of meaning of <code>()</code> in function declarators ====
In earlier C versions, a declaration `int function()` declares
`function` as accepting an unspecified number of arguments of unknown
type. This means that both `function(1)` and `function("one")`
compile, even though they might not work correctly. In a future C
standard, `int function()` will mean that `function` does not accept
any parameters (like in C++, or as if written as `int function(void)`
in current C). Calls that specify parameters will therefore result in
compilation errors.
We believe that this change is ABI-compatible, even on ppc64le (with
its parameter save area), although it comes very close to an implicit
ABI break.
==== Rejecting implicit conversions between integers and pointers as errors ====
Currently, GCC does not treat conversion between integers at pointers
as errors, so this compiles:
<pre>
int ptr = "string";
</pre>
However, this is very unlikely to work on 64-bit architectures (it may
work by accident without PIE/PIC).
== Feedback ==
The transition plan has been discussed at various GNU Tools Cauldrons.
Feedback has been generally positive, except a general worry about the
work required.
Without a deliberate porting effort, a lot of breakage occurs,
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
seen in 2016 in Fedora with an uncoordinated change], and more
recently [https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-…
an uncoordinated Clang update].
== Benefit to Fedora ==
Programmers will no longer waste time tracking down things that look
eerily like compiler or ABI bugs because in several cases, builds will
fail with a clear error message, instead of producing a warning that
is easily missed. Potential blockers to adoption of further C language
changes are removed.
== Scope ==
* Proposal owners: Update rawhide over time to be compatible with
strict C99 compilers.
* Other developers: Help out with non-obvious porting issues, and with
upstreaming patches in case active upstreams cannot be easily
identified. Tolerate early backports of upstream-submitted fixes in
Fedora dist-git.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: Fedora compiler policy will likely change
due to the adoption of GCC 14 in Fedora 40.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
The change is expected to be transparent to those users who do not use
C compilers. No features are supposed to be added or removed as a
result. In fact, most of the porting effort focuses on avoiding
configuration changes.
== How To Test ==
General regression testing is sufficient.
== User Experience ==
User experience does not change.
== Dependencies ==
To avoid regressing the porting effort, GCC as the system compiler
needs to reject obsolete constructs by default. This is expected for
GCC 14, to be released as part of Fedora 40 in Spring 2024.
== Contingency Plan ==
* Contingency mechanism: Upstream GCC will probably accept obsolete
constructs longer in case distributions like Fedora cannot port to
modern C in time.
* Blocks release? No if GCC doesn't switch. If GCC switches, we have
to complete the port.
== Documentation ==
This section will be updated once more documentation of the porting
effort will become available.
== Release Notes ==
Probably not needed because no user visible impact is intended.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/ModernizeLiveMedia
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 ==
Modernize the live media by switching to the "new" live environment
setup scripts provided by {{package|livesys-scripts}} and leverage new
functionality in {{package|dracut}} to enable support for
automatically enabling persistent overlays when flashed to USB sticks.
== Owner ==
* Name: [[User:Ngompa|Neal Gompa]], [[User:Mcoleman|Matt Coleman]]
* Email: ngompa13(a)gmail.com, matt(a)1eanda.com
== Detailed Description ==
As part of preparing to change our tooling around producing images, we
need to update the way we produce working live media. This has been
done in two parts: the live environment setup scripts have been
reworked to run properly through systemd and are packaged in
{{package|livesys-scripts}} and new functionality in
{{package|dracut}} has been added to enable support for automatically
enabling persistent overlays when flashed to USB sticks so that
<code>livecd-iso-to-disk.sh</code> can be retired.
== Benefit to Fedora ==
Since we introduced [[Releases/FeatureLiveCD|live media in Fedora
Linux 7]], the actual mechanism in which the live environment sets
itself up has been complex and intricately tied to the method in which
we produce the media (using Kickstarts). The nature of the
implementation of those scripts means that they are hard to understand
and debug, which has caused problems in the past whenever we've needed
to update them.
As we look forward to new and better tooling for producing images
(such as {{package|kiwi}} and {{package|osbuild}}), we cannot continue
to rely on kickstart-driven image builds that construct shell scripts
on the fly to embed in the image as we do now. With
{{package|livesys-scripts}}, those scripts have been simplified and
turned into systemd services that activate only in live environments.
This also gives us the opportunity to introduce new functionality for
live media. [https://github.com/dracutdevs/dracut/pull/1991 New
functionality was added to dracut] and
[https://src.fedoraproject.org/rpms/dracut/pull-request/26 backported
to Fedora] so that we can retire the remaining usage of
<code>livecd-iso-to-disk.sh</code> and provide a better experience
with our live media, particularly for portable backup and rescue
environments by introducing the ability to automatically setup
persistence on boot when unpartitioned space is detected on a USB
stick on boot.
== Scope ==
* Proposal owners:
** Modify [https://pagure.io/fedora-kickstarts fedora-kickstarts] to
drop embedded livesys setup scripts and use
{{package|livesys-scripts}}
** Add <code>livesys.service</code> and
<code>livesys-late.service</code> to the systemd presets in
{{package|fedora-release}}
** [https://src.fedoraproject.org/rpms/dracut/pull-request/26 Backport
<code>dmsquash-live-autooverlay</code> module] to {{package|dracut}}
** Modify [https://github.com/weldr/lorax/tree/master/share/templates.d/99-generic
lorax-generic-templates] to offer menu entries for configuring the
persistent overlay
* Other developers:
** Anaconda may need adaptations to correctly filter out more live
environment specific boot arguments when configuring the installed
environment.
* Release engineering: [https://pagure.io/releng/issue/11091 #11091]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
There should be no impact here, as this affects only the live environment.
== How To Test ==
Once the changes are merged, simply try to boot produced live media.
There should be new options for resetting the persistent overlay and
booting with no persistence. The default options should boot with
persistence and setup of persistence should work.
Testing persistence behavior is simple:
# Boot normally
# Create a file in the home directory
# Reboot into the environment
# See the file is there still
Testing the reset behavior would go similar to the regular test,
except you should expect the file to not show up in step 4. Same for
booting with no persistence.
Otherwise, the media should work like before, and things like live
installation should work as expected.
== User Experience ==
When booting live media, two new menu options will become available:
one to reset the persistent overlay while booting, and one to boot
without persistence. The default boot options will create a persistent
overlay if it doesn't exist and can be written (e.g. when booting from
a USB stick).
== Dependencies ==
* [https://pagure.io/fedora-kickstarts fedora-kickstarts]
* {{package|anaconda}}
* {{package|dracut}}
* {{package|livesys-scripts}}
* {{package|lorax}}
== Contingency Plan ==
* Contingency mechanism: Revert changes to fedora-kickstarts and lorax
to go back to previous behavior
* Contingency deadline: Final Freeze
* Blocks release? Yes
== Documentation ==
Information on the persistent overlay functionality is included in the
Dracut documentation.
== Release Notes ==
By default, Fedora Linux live environments flashed to writable USB
media with sufficient free space will maintain user changes to the
environment. This "persistence" can be reset at boot time through the
boot menu.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/LXQt_image_for_aarch64
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 ==
Generate LXQt image (both iso and disk image) for aarch64 architecture.
== Owner ==
* Name: [[User:Zsun|Zamir SUN]]
* Email: zsun#AT#fedoraproject.org
== Detailed Description ==
LXQt has moved out of 0.x version and is now 1.1.0, so I consider it
to be a pretty stable desktop environment. Recently, 64bit ARM
architecture is becoming more and more popular in laptops and
workstations. By generating a LXQt image for aarch64 will offer
aarch64 another easier option to evaluate and use Fedora.
== Benefit to Fedora ==
Offers users of 64bit ARM architecture another desktop option that
works out-of-the-box.
== Scope ==
* Proposal owners: Nothing. The LXQt packages are already in the
distribution. And the kickstart for generating LXQt image on x86_64
can be directly used.
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issue/11086 11086]
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
Install using the ISO or the disk image on aarch64 system. The system
should work as it should be by manually installing on top of any
existing aarch64 system.
== User Experience ==
Users of aarch64 systems should be able to directly install from LXQt
ISO or disk image if they want to use LXQt.
== Dependencies ==
We need to ask release engineering team to generate the image.
== Contingency Plan ==
* Contingency mechanism: Just do not ship the newly generated image.
* Contingency deadline: Fedora 38 Beta Freeze
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable
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 ==
Continue the work done in
https://fedoraproject.org/wiki/Changes/OstreeNativeContainer but in an
officially stable format, and expanded to cover more OSTree-based
editions. This goes "all in" on being container-native and
significantly changes the technology and user emphasis.
== Owner ==
* Name: [[User:walters| Colin Walters]], [[User:jmarrero| Joseph
Marrero]], [[User:baude| Brent Baude]]
* Email: walters(a)verbum.org, jmarrero(a)fedoraproject.org, baude(a)fedoraproject.org
== Detailed Description ==
* rpm-ostree's functionality to
[https://coreos.github.io/rpm-ostree/container/ boot and upgrade from
Docker/OCI container images] is declared stable
* Rework Fedora editions and spins (CoreOS, IoT, Silverblue, Kinoite,
etc) that use ostree to instead deliver via Docker/OCI container
images
* `rpm-ostree` is reworked to gain strong CLI compatibility with
`yum/dnf` commands (cliwrap)
* The new container native functionality is exposed via `dnf image`
* (TBD: Rebranding of rpm-ostree itself to `dnf-image` or something else)
* Support and documentation for generating derived images
* Support in Anaconda and other tools
* Support for generating bootable images
A top level goal is that users should not need to know or understand
ostree (or rpm-ostree); they only need to know containers and most key
functionality is exposed via the `yum/dnf` frontend with a few
extensions.
=== Backwards compatibility ===
If you're a user of ostree today: no need to worry. Everything that
works today in ostree and rpm-ostree will continue to work for years
to come (it's shipped in RHEL9). However, it's expected that most
users will find the new model sufficiently compelling to switch fairly
quickly.
=== Stable Bootable OCI ===
More information about this is available in
[https://coreos.github.io/rpm-ostree/container/ the rpm-ostree
documentation]. This Change highlights that this functionality is
planned to be officially stable.
=== Changing to OCI over the wire ===
Today Fedora has an OSTree repository that contains updates for
editions such as Fedora CoreOS and Fedora Silverblue.
These editions instead will become [https://github.com/opencontainers
OCI base images], available at e.g.
* `quay.io/fedora/fedora-coreos:stable`
([https://quay.io/repository/fedora/fedora-coreos this exists today]!)
* `quay.io/fedora/fedora-silverblue:38` (does not exist, but can soon)
An update will be shipped that will cause existing systems tracking
the production ostree branches to be switched to the corresponding
container image. Concretely for example, a system running
`fedora:fedora/36/x86_64/silverblue` will execute `rpm-ostree rebase
ostree-remote-registry:fedora:quay.io/fedora/fedora-silverblue:36`.
Note that at the current time, Fedora does not sign container images.
This should change (likely to something based on
[cosign](https://github.com/containers/skopeo/pull/1701)) but in the
mean time, the ostree-container flow supports verifying the embedded
ostree-baesd GPG signatures and this will continue to be used.
The Fedora OSTree repository will become read-only and stop receiving updates.
Note that for Fedora CoreOS specifically, there is some outstanding
design discussion around the intersection with Cincinnati:
https://github.com/coreos/fedora-coreos-tracker/issues/1263
==== Wire efficiency ====
Today the container images generated by rpm-ostree are "chunked" in a
reproducible fashion; for more information on this, see
* https://github.com/ostreedev/ostree-rs-ext/issues/69
* https://coreos.github.io/rpm-ostree/container/
However, longer term (as that first issue notes) we do want to add
[https://github.com/containers/image/pull/902 container deltas].
Doing so will benefit non-host containers too.
=== dnf/yum CLI compatibility ===
rpm-ostree has a feature called
[cliwrap](https://coreos.github.io/rpm-ostree/cliwrap/) today. A key
motivation here is that in the switch to using containers as the
frontend, the project name "rpm-ostree" (which is very literal) no
longer makes sense. A further emphasis on "container native" will
strongly encourage writing e.g. a `Dockerfile` like this:
<pre>
FROM quay.io/fedora/fedora-silverblue:stable
RUN dnf -y install sway && ostree container commit
</pre>
*Today*, one can spell this as `RUN rpm-ostree install -y sway &&
ostree container commit` - but a toplevel goal here is to allow host
system customization using the same patterns and tools one uses to
build application containers, and to de-emphasize the "ostree backend"
aspect.
To complete this story on the client side, what is today called
"ostree native containers" will be exposed via a new `dnf image`
subcommand on the client system.
For example:
<pre>
$ dnf image rebase quay.io/examplecorp/customos:latest
</pre>
As well as other offline/"image based" functionality such as `dnf
image rollback` and `dnf image apply-live`.
However, as many people know, rpm-ostree does today support
"per-machine" package layering/overrides - and *that will continue to
work*. So users are not *required* to do builds on a remote server
even in "image mode".
Concretely, it will also work to `sudo dnf -y install sway` inside a
root terminal on a Fedora Workstation for example. This will still be
a transactional operation.
More: https://github.com/coreos/rpm-ostree/issues/2883
=== Rebranding of rpm-ostree ===
This is a fundamental change in technology *and* positioning for
rpm-ostree (and for the projects that use it). The terminology of
"immutable" gets even fuzzier now (see also [this
blog](https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionabl…)
It would make sense to rebrand the project due to this. No decision
has been made on this, but the choices are:
- Keep as is
- Rebrand to dnf-image (or, reviving a past name, yum-image)
- Rebrand to something else
More: https://github.com/coreos/rpm-ostree/issues/405
=== Support for building derivative containers ===
Until now, the model for systems like Fedora CoreOS and Silverblue
etc. has included an emphasis on containerization, but avoiding
extensive customization of the host system. This will be weakened
somewhat - it will be fully supported to build derivative operating
system images that in turn contain software which itself should run
directly on the host system, and not in a container.
A key aspect of this is that by generating a custom build, one binds
together the code and configuration as a transactionally updatable
unit.
The role of things like Kickstart, cloud-init, and Ignition and other
system config management shrinks significantly.
=== Example 1: Kubernetes and kubelet ===
It is not supported upstream to run the kubelet in a container image
itself. Today, for OpenShift 4 we embed the kubelet as part of the
CoreOS builds. The [https://www.okd.io/ OKD] project
[https://github.com/openshift/okd-machine-os/blob/fa2248d332abc9926e68428dc6…
already installs kubelet during a container build] deriving from the
base `fedora-coreos` image. It is possible that RHEL CoreOS will make
[https://github.com/openshift/os/issues/799 a similar split].
=== Example 2: Agent software ===
Many organizations require agents (cloud agents, security scanners,
antivirus) which are not ready to be containerized. Often too, these
tools come in e.g. RPM form, and also expect to be configured (remote
logging server, etc.). This tooling allows to `dnf install` these
*and* embed the configuration, generating a standard container image
which can then be booted as an atomic unit.
(Note that in the OpenShift context, we expect this to chain with the
first example - users instead derive from a `okd-node-base` image
which itself derives from `fedora-coreos`).
=== Example 3: Podman machine ===
The `[http://podman.io Podman]` project has a function called
`[https://github.com/containers/podman/blob/main/docs/source/markdown/podman-machine.1.md
machine]` where it creates a virtual machine and boots standard CoreOS
builds. Podman developers and users has long desired a custom FCOS
image that is focused on container deployment using Podman, including
certain QEMU packages that allow for cross-architecture development.
This approach will solve a series of problems including but not
limited to getting more timely release alignment between Podman and
FCOS.
We also have a user base that wants to customize the VM image based on
restrictive environments ... bring your own virtual machine image.
=== Support in Anaconda and other tools ===
Anaconda support for custom images is tracked in this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=2125655
But, as part of this Change, it should also work to generate an
Anaconda ISO which allows *user choice* for whether to install in
"image mode" or "traditional".
=== Support for generating bootable images ===
Instead of using an existing disk image/ISO (Anaconda, AWS AMI, etc.)
and then doing an in-place update to a generated container image, in
many cases will want to generate disk images using their container
image as input.
For example, generating an ISO that embeds that container image as
input and will install it.
In this proposal, we plan to ship a container image as part of Fedora
CoreOS that will do this:
https://github.com/coreos/fedora-coreos-tracker/issues/1151
But, it also makes sense to have a tool that e.g. does this and
generates an Anaconda ISO (we will inherently be doing this as part of
generating ostree-based Anaconda ISOs already!) - this would just be
supporting that in a clear external way too. One likely target for
this is [https://github.com/osbuild osbuild] and
[https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/ht…
RHEL Image Builder].
== Feedback ==
== Benefit to Fedora ==
The need to understand ostree goes away for most users; they
understand RPMs and containers. While retaining all the current
(rpm-)ostree features.
== Scope ==
* Proposal owners:
* Other developers: May affect e.g. gnome-software and similar tools
that talk to rpm-ostree.
* Release engineering: [https://pagure.io/releng/issue/11047]
* Policies and guidelines: None.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: None
== Upgrade/compatibility impact ==
We will ship a systemd unit that transitions systems currently using
OSTree on the wire over to tracking the corresponding container
images. Note again, all features of rpm-ostree continue to work! For
example, if you have layered packages, that will continue to be
applied.
== How To Test ==
Build container images, boot them.
== User Experience ==
Users will not need to understand ostree (at least at a superficial
level), only container images.
== Dependencies ==
Needs improvements in Anaconda in some cases, also would like to
increase alignment with dnf. Fetching container images uses `skopeo`,
maintained by containers team.
== Contingency Plan ==
* Contingency mechanism: Continue to ship things the way we ship them today
* Contingency deadline: Dunno
* Blocks release? No
== Documentation ==
https://coreos.github.io/rpm-ostree/container/ and
https://github.com/coreos/coreos-layering-examples etc.
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/PostgreSQL_15
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.
== Owner ==
* Name: [[User:osloup| Ondřej Sloup]]
* Email: osloup(a)redhat.com
== Detailed Description ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from version 14 to version 15 in the non-modular (main) builds.
This also involves moving the postgresql-static subpackage to libpq
creating the libpq-static subpackage.
=== Plan ===
* Prepare PostgreSQL 15 in Copr (TBD)
* Rebuild important dependencies in Copr (TBD)
* Debug and fix compatibility issues found in dependencies (a
reasonable amount of non-critical in FTBFS state might be tolerable)
* Build in a "side tag" to prevent dependencies from failing and
rollout once stable
* Prepare Pull requests in Rawhide
* Merge and build into a "side tag"
* Once stable merge into Rawhide
== Feedback ==
== Benefit to Fedora ==
The latest stable software is used by Fedora users, providing
additional features and fixes.
== Scope ==
* Proposal owners:
**Prepare PostgreSQL 15
**Prepare PostgreSQL 14 as a module for Rawhide
**Check software that requires or depends on `postgresql-server` or
`libpq` packages for incompatibilities
**Build PostgreSQL 15 (postgresql and libpq) to Rawhide
**Rebuild depended on packages against PostgreSQL 15
**Gather user input on the changes between PostgreSQL 14 and PostgreSQL 15
* Other developers: N/A
* Release engineering:
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The PostgreSQL client library (libpq component) is compatible. So,
there shouldn't be any compatibility issues, but rebuilding the
dependent components is recommended.
Server plugins might require a newer version update because they
sometimes have explicit server requirements. PostgreSQL maintainer
will help fix/rebuild any issues in the plugins.
How to upgrade your database data from one PostgreSQL release to a
newer one is described in
[https://www.postgresql.org/docs/15/upgrading.html Upgrading a
PostgreSQL Cluster]
== How To Test ==
Usual testing when upgrading between major PostgreSQL versions is
running `postgresql-setup --upgrade` necessary between major versions.
Test that all other software runs well with PostgreSQL 15.
== User Experience ==
The users will have to upgrade their databases the same way as major
PostgreSQL versions, aka `postgresql-setup --upgrade` after installing
PostgreSQL 15 server packages.
If users want to stick with PostgreSQL 14 for a little longer, there
will be PostgreSQL 14 module.
== Dependencies ==
Some packages (mostly server plugins) build on top of PostgreSQL.
Since the separation of the 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 make sure all
potential binary incompatibilities are handled.
* PostgreSQL server dependencies
** 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 ==
Revert changes in the non-modular packages and provide PostgreSQL 15
as a module stream only.
== Documentation ==
Upgrade strategy: https://www.postgresql.org/docs/15/upgrading.html
== Release Notes ==
Release notes for PostgreSQL 15 release:
https://www.postgresql.org/docs/15/index.html
Overall overview of the changes and improvements:
https://www.postgresql.org/docs/15/release-15.html
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/RpmSequoia
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 RPM to use [https://sequoia-pgp.org/ Sequoia] based OpenPGP
parser instead of it's own, flawed and limited implementation.
== Owner ==
* Name: [[User:pmatilai| Panu Matilainen]]
* Email: pmatilai(a)redhat.com
== Detailed Description ==
For the last 20 years or so, RPM has used a home-grown OpenPGP parser
for dealing with keys and signatures. That parser is rather infamous
for its limitations and flaws, and especially in recent years has
proven a significant burden to RPM development. In order to improve
security and free developer resources for dealing with RPM's "core
business" instead, RPM upstream is in the process of deprecating the
internal parser in favor of [https://sequoia-pgp.org/ Sequoia PGP]
based solution written in Rust.
At this point the change is mostly invisible in normal daily use.
== Feedback ==
== Benefit to Fedora ==
The main, direct benefit to Fedora is improved security and
standards-compliance (RFC-4880) in one of the corner-stones of the
whole distribution. Longer term, we can expect better error messages
and other functional improvements regarding key and signature
handling.
== Scope ==
* Proposal owners:
** Help [https://bugzilla.redhat.com/show_bug.cgi?id=2087499
package/review rpm-sequoia]
** Build rpm with --with-crypto=sequoia
** Watch out for the unexpected
* Other developers:
** Help [https://bugzilla.redhat.com/show_bug.cgi?id=2087499
package/review rpm-sequoia]
* Release engineering: [https://pagure.io/releng/issue/11077 #11077]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Within Fedora package set, this has no impact as everything is already
using sufficiently strong crypto. Third party repositories / packages
could be signed with insecure crypto, and those may require working
around with --nosignature. However this incidentally overlaps with
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2
which has effectively the same effect on rpm.
== How To Test ==
In general, normal rpm/dnf use provides sufficient test coverage. For
more advanced testers: try signing and verifying with different keys
and their subkeys, using different algorithms etc.
== User Experience ==
For normal usage, the change is quite invisible. The notable exceptions are
- Some old, insecure (MD5/SHA1 based) signatures are rejected (this is
in line with the stronger crypto settings proposed elsewhere for F38)
- Key import may accept some previously rejected keys, in part due to
limitations of old parser etc but in particular, the old
implementation verifies self-signatures at import time whereas Sequoia
verifies them at time of use.
- Key import may reject some previously accepted keys due to better validation.
== Dependencies ==
The change introduces one new direct dependency:
[https://github.com/rpm-software-management/rpm-sequoia/ rpm-sequoia].
The rpm-sequoia package also takes over other crypto besides OpenPGP,
currently Sequoia uses nettle as its low-level crypto provider, but
work is underway to
[https://gitlab.com/sequoia-pgp/sequoia/-/merge_requests/1361 support
openssl in Sequoia], and the plan is to have Sequoia in Fedora use
that once it becomes available. This plan
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
has support of the crypto team].
== Contingency Plan ==
* Contingency mechanism: Revert back to the internal PGP parser
* Contingency deadline: Beta release
* Blocks release? No
== Documentation ==
There's not much in the way of documentation as there's not much to
document, except for the deprecation of the internal parser:
https://github.com/rpm-software-management/rpm/issues/1935
rpm-sequoia build instructions can be found in
https://github.com/rpm-software-management/rpm-sequoia/
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
There is an ongoing BOS power outage impacting s390x builders.
Reason for outage: Power outage in the DC
--
Tomas Hrcka
role: CPE Team - Senior Software Engineer
fas: humaton
freenode: jednorozec
https://fedoraproject.org/wiki/Changes/DeprecatePythonToml
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 {{package|python-toml}} (`python3-toml`) package will be
[https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packa…
deprecated] in [[Releases/38|Fedora 38]]. The
[https://pypi.org/project/toml/ upstream toml package] is considered
unmaintained (see [[#Detailed_Description|description]]) and Python
3.11 contains [https://peps.python.org/pep-0680/ a TOML-reading
library in the standard library]. Existing Fedora packages depend on
{{package|python-toml}}, so we cannot remove it yet. Packagers are
encouraged to work with upstreams to switch to
[https://peps.python.org/pep-0680/tomllib]/[https://pypi.org/project/tomli/ tomli] for reading toml or
[https://pypi.org/project/tomli/ tomli-w] for writing it. But
{{package|python-toml}} remains available until it is a leaf package,
it will be removed then (possibly not yet in Fedora 38).
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhroncok(a)redhat.com
== Detailed Description ==
The {{package|python-toml}} package is [https://pypi.org/project/toml/
unmaintained upstream]. It does not support the latest TOML standard
and no longer releases newer versions.
We'd like to drop it from Fedora, but several packages still require
it. Before we attempt to remove the package, we need to stop new
packages to (Build)Require `python3-toml`, hence we want to have it
[https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packa…
deprecated]. No new packages that require it may be added to Fedora
and existing packages may not gain new dependencies on it. Requiring
it only `if python3 < 3.11` or similar is allowed because python3 on
Fedora 38 is 3.11.
Packagers are encouraged to switch to an alternative TOML library with
upstream involvement. Downstream-only patches to switch are not
encouraged. Change owners recommend the following alternatives:
* Use the [https://docs.python.org/3.11/library/tomllib.html tomllib]
module from the standard library to read TOML with Python 3.11+.
* Use the {{package|python-tomli}} package to read TOML with an older
version of Python. The `tomllib` module has started as `tomli` and
they share the same API except for the module name.
* Use the {{package|python-tomli-w}} package to write TOML.
Note that <code>repoquery</code> gives many packages depending on
`python3-toml`:
$ repoquery --repo=rawhide{,-source} --whatrequires python3-toml | wc -l
443
This is because many packages BuildRequire `(python3dist(toml) if
python3-devel < 3.11)` due to {{package|pyproject-rpm-macros}}.
$ repoquery --repo=rawhide{,-source} --whatrequires
'(python3dist(toml) if python3-devel < 3.11)' | wc -l
413
The change owners don't know how to
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
easily filter them out], but when filtered the hard way, this remains:
(Results from 2022-10-05, may contain false positives.)
$ for pkg in $(repoquery --repo=rawhide{,-source} --whatrequires
python3-toml); do repoquery -q --repo=rawhide{,-source} --requires
$pkg | grep -Fv '(python3dist(toml) if python3-devel < 3.11)' | grep
-Eq '(\(|-)toml\b' && echo $pkg; done
academic-admin-0:0.5.1-10.fc37.noarch
academic-admin-0:0.5.1-10.fc37.src
bandit-0:1.7.4-3.fc37.src
bst-external-0:0.29.0-1.fc38.src
cvc4-0:1.8-12.fc37.src
fedora-license-data-0:1.5-1.fc38.src
fedora-messaging-0:3.1.0-5.fc38.src
gi-docgen-0:2022.1-7.fc38.noarch
gi-docgen-0:2022.1-7.fc38.src
jrnl-0:3.0-3.fc37.src
micropipenv-0:1.4.2-1.fc37.noarch
pre-commit-0:2.20.0-2.fc37.noarch
pre-commit-0:2.20.0-2.fc37.src
pylint-0:2.14.4-3.fc37.src
python-anyconfig-0:0.13.0-3.fc37.src
python-anymarkup-0:0.8.1-10.fc37.src
python-anymarkup-core-0:0.8.1-9.fc37.src
python-ast-monitor-0:0.2.1-1.fc38.src
python-asttokens-0:2.0.8-1.fc38.src
python-autopep8-0:1.6.0-5.fc37.src
python-botocore-0:1.27.86-1.fc38.src
python-box-0:6.0.2-1.fc38.src
python-build-0:0.8.0-4.fc37.src
python-check-manifest-0:0.48-3.fc37.src
python-deepdiff-0:5.8.2-2.fc37.src
python-devicely-0:1.1.1-3.fc37.src
python-elpy-0:1.34.0-8.fc37.src
python-exoscale-0:0.7.1-4.fc37.src
python-fasjson-client-0:1.0.7-5.fc38.src
python-fireflyalgorithm-0:0.3.2-2.fc37.src
python-interrogate-0:1.5.0-4.fc37.src
python-jsonpickle-0:2.2.0-4.fc37.src
python-lsp-black-0:1.2.0-3.fc37.src
python-matrix-nio-0:0.19.0-6.fc38.src
python-molecule-podman-0:1.0.1-4.fc37.src
python-neurom-0:3.1.0-5.fc37.src
python-niaaml-0:1.1.11-1.fc38.src
python-niaarm-0:0.2.1-2.fc38.src
python-niaclass-0:0.1.2-8.fc37.src
python-nikola-0:8.2.2-4.fc37.src
python-pendulum-0:2.1.2-8.fc37.src
python-podman-3:4.2.0-7.fc38.src
python-pyedflib-0:0.1.30-2.fc37.src
python-pyqt-feedback-flow-0:0.1.6-3.fc37.src
python-rich-0:12.6.0-1.fc38.src
python-rst-linker-0:2.3.1-1.fc38.src
python-sklearn-nature-inspired-algorithms-0:0.9.0-3.fc37.src
python-sport-activities-features-0:0.3.6-1.fc38.src
python-stochastic-0:0.7.0-2.fc37.src
python-toml-adapt-0:0.2.7-3.fc37.src
python-usort-0:0.6.3-7.fc37.src
python-vulture-0:2.6-1.fc38.src
python3-anymarkup-0:0.8.1-10.fc37.noarch
python3-autopep8-0:1.6.0-5.fc37.noarch
python3-box-0:6.0.2-1.fc38.noarch
python3-exoscale-0:0.7.1-4.fc37.noarch
python3-fasjson-client-0:1.0.7-5.fc38.noarch
python3-fedora-messaging-0:3.1.0-5.fc38.noarch
python3-interrogate-0:1.5.0-4.fc37.noarch
python3-jaraco-functools-0:3.5.2-1.fc38.noarch
python3-jinja2-cli-0:0.8.2-3.fc37.noarch
python3-lsp-black-0:1.2.0-3.fc37.noarch
python3-nikola-0:8.2.2-4.fc37.noarch
python3-podman-3:4.2.0-7.fc38.noarch
python3-sklearn-nature-inspired-algorithms-0:0.9.0-3.fc37.noarch
python3-toml-adapt-0:0.2.7-3.fc37.noarch
python3-usort-0:0.6.3-7.fc37.noarch
python3-vulture-0:2.6-1.fc38.noarch
rpmlint-0:2.2.0-7.fc38.noarch
rpmlint-0:2.2.0-7.fc38.src
sip6-0:6.6.2-2.fc37.src
sip6-0:6.6.2-2.fc37.x86_64
teampulls-0:0.2.2-10.fc37.noarch
trac-tracnav-plugin-0:4.3-7.fc37.src
=== List of components still (Build)Requiring python3-toml ===
* {{package|academic-admin}}
* {{package|bandit}}
* {{package|bst-external}}
* {{package|cvc4}}
* {{package|fedora-license-data}} (false positive, dependency
conditional on python3 < 3.11)
* {{package|fedora-messaging}}
* {{package|gi-docgen}}
* {{package|jrnl}}
* {{package|micropipenv}} (already fixed in the meantime)
* {{package|pre-commit}}
* {{package|pylint}}
* {{package|python-anyconfig}}
* {{package|python-anymarkup}}
* {{package|python-anymarkup-core}}
* {{package|python-ast-monitor}}
* {{package|python-asttokens}}
* {{package|python-autopep8}}
* {{package|python-botocore}}
* {{package|python-box}}
* {{package|python-build}}
* {{package|python-deepdiff}}
* {{package|python-devicely}}
* {{package|python-elpy}}
* {{package|python-exoscale}}
* {{package|python-fasjson-client}}
* {{package|python-fireflyalgorithm}}
* {{package|python-check-manifest}}
* {{package|python-interrogate}}
* {{package|python-jaraco-functools}} (superfluous,
[https://src.fedoraproject.org/rpms/python-jaraco-functools/pull-request/5
proposed fix])
* {{package|python-jinja2-cli}}
* {{package|python-jsonpickle}}
* {{package|python-lsp-black}}
* {{package|python-matrix-nio}}
* {{package|python-molecule-podman}}
* {{package|python-neurom}}
* {{package|python-niaaml}}
* {{package|python-niaarm}}
* {{package|python-niaclass}}
* {{package|python-nikola}}
* {{package|python-pendulum}}
* {{package|python-podman}}
* {{package|python-pyedflib}}
* {{package|python-pyqt-feedback-flow}}
* {{package|python-rich}}
* {{package|python-rst-linker}}
* {{package|python-sklearn-nature-inspired-algorithms}}
* {{package|python-sport-activities-features}}
* {{package|python-stochastic}}
* {{package|python-toml-adapt}}
* {{package|python-usort}}
* {{package|python-vulture}}
* {{package|rpmlint}} (already fixed in the meantime)
* {{package|sip6}}
* {{package|teampulls}}
* {{package|trac-tracnav-plugin}}
Once all dependencies are removed, we plan to retire
{{package|python-toml}}, whether it will be in Fedora 38 (unlikely) or
later.
=== Migrating to tomllib ===
* Remove any `toml` requirements from upstream metadata.
* Change all `toml` imports to `tomllib` imports.
* Change all references of `TomlDecodeError` to `TOMLDecodeError`.
* Open files in binary mode, if passing file objects to `tomllib.load()`.
=== Migrating to tomli ===
* Change any `toml` requirements in upstream metadata to `tomli`.
* Change all `toml` imports to `tomli` imports.
* Change all references of `TomlDecodeError` to `TOMLDecodeError`.
* Open files in binary mode, if passing file objects to `tomli.load()`.
=== Migrating to tomllib on Python 3.11+ and falling back to tomli ===
* Change any `toml` requirements in upstream metadata to
`tomli;python_version<"3.11"`.
* Change all `toml` imports to `sys.version_info`-conditional or `try:
except ImportError:` `tomli`/`tomllib` imports.
* Change all references of `TomlDecodeError` to `TOMLDecodeError`.
* Open files in binary mode, if passing file objects to `tomllib.load()`.
Example of importing:
try:
import tomllib
except ImportError:
import tomli as tomllib
Or:
if sys.version_info < (3, 11):
import tomli as tomllib
else:
import tomllib
Upstream example: https://github.com/pytest-dev/pytest/pull/9741
A more complex example that also falls back to `toml` on Python 2.7 or
3.6: https://github.com/tox-dev/tox/pull/2463
A more complex example that supports `pytoml`, `toml`, `tomli` and
`tomllib`: https://github.com/thoth-station/micropipenv/pull/241
=== Migrating to tomllib on Python 3.11+ and falling back to toml ===
Despite `toml` not being maintained upstream, it exists in EPEL 8,
unlike `tomli` (currently).
Some Fedora-upstream projects might need to migrate to `tomllib` but
keep using `toml` on older Pythons.
* Change any `toml` requirements in upstream metadata to
`toml;python_version<"3.11"`.
* Change all `toml` imports to `sys.version_info`-conditional or `try:
except ImportError:` `tomli`/`tomllib` imports.
* Change all references of `TomlDecodeError` to `TOMLDecodeError`
depending on what was imported.
* Open files in binary/text mode depending on what was imported.
try:
import tomllib as toml_module
toml_mode = "rb"
toml_exception = toml_module.TOMLDecodeError
except ImportError:
import toml as toml_module
toml_mode = "r"
toml_exception = toml_module.TomlDecodeError
with open(..., toml_mode) as f:
try:
_ = toml_module.load(f)
except toml_exception as e:
...
Example upstream PR: https://github.com/fedora-infra/fedora-messaging/pull/274
=== Migrating to tomli-w ===
* Change any `toml` requirements in upstream metadata to `tomli-w`.
* Change all `toml` imports to `tomli_w` imports.
* Open files in binary mode, if passing file objects to `tomli_w.dump()`.
A more complex example that migrates to `tomli`, `tomllib` and
`tomli-w`: https://github.com/rpm-software-management/rpmlint/pull/905
== Feedback ==
== Benefit to Fedora ==
An upstream dead package will not be depended upon by new packages.
== Scope ==
* Proposal owners: Deprecate `python3-toml`. Work with packagers and
upstream developers to remove the dependency. Monitor the remaining
dependent packages and eventually retire {{package|python-toml}}
(unlikely in Fedora 38).
* Other developers: No action needed. Don't add new dependencies on
`python3-toml`.
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The package will remain available. Only new packages cannot depend on it.
Once retired, we don't plan to provide <code>python3-toml</code> from
`python3-libs` or `python3-tomli`, because it cannot work as a drop-in
replacement (the Python module has a different name and slightly
different API). The package will eventually be obsoleted by
{{package|fedora-obsolete-packages}} once retired, but that is
unlikely to happen soon.
== How To Test ==
$ repoquery --repo=rawhide --provides python3-toml
...
deprecated()
...
== User Experience ==
No changes.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: revert the deprecation
* Contingency deadline: Final Freeze
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis