F38 proposal: Prevent from building RPM packages providing
python3dist(...) = 0 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Prevent-Providing-python3dist(pkg)...
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 ==
It sometimes happens that Python packages succeed to build as RPM with
incorrect version metadata.
They generate a wrong provide in format `python3dist(...) = 0` and
`python3.Xdist(...) = 0`.
While version `0` (or equal versions like `0.0` or `0.0.0`) is
probably technically valid, in most cases this indicates a packaging
error.
We propose to prevent this error from happening by explicitly failing
the RPM build instead of generating such provides.
== Owner ==
* Name: [[User:Ksurma|Karolina Surma]]
* Email: ksurma(a)redhat.com
== Detailed Description ==
This change is about automatic RPM provides in the following form:
* `python3dist(distname) = 0`
* `python3.Xdist(distname) = 0`
Where X is the Python minor version (eg. 10, 11...).
It does not affect any other provides.
More about these provides:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Machine...
The provides generated during the RPM build come from the upstream
Python package metadata.
Some Python building backends, eg. setuptools, explicitly allow
creating package with version `0.0.0` when the version used by a
project is not known. This was
[https://github.com/pypa/setuptools/issues/2329 discussed upstream]
with conclusion that it's an intended behavior.
In other cases, for example when building package from a particular
git commit, the incorrect provide can be generated due to a packaging
error.
We've never encountered a situation when packaging the version `0` was
the package maintainers intention.
After a discussion on python-devel mailing list we agreed we'd like to
prevent such situations from happening in Fedora.
An example of the incorrect provides:
$ rpm -qpP python3-ssh-python-0.10.0-5.fc38.x86_64.rpm
python-ssh-python = 0.10.0-5.fc38
python3-ssh-python = 0.10.0-5.fc38
python3-ssh-python(x86-64) = 0.10.0-5.fc38
python3.11-ssh-python = 0.10.0-5.fc38
'''python3.11dist(ssh-python) = 0'''
'''python3dist(ssh-python) = 0'''
Why is it bad?
If any package requires `python3-ssh-python > 0.9` (correctly assuming
there's `0.10.0` in Fedora's repositories), the automatic dependency
generators will not discover the example package, making the other
package non-installable.
In January 2022 the
[https://bugzilla.redhat.com/showdependencytree.cgi?id=python3dist0
umbrella Bugzilla ticket] was created for Python packages providing
version `0`. In all cases the automatic provide wasn't intended.
Affected packages (as of Nov 11 2022):
b43-tools
dionaea
marisa
python-podman-api
rpkg
spectrographic
python-ssh-python
python-streamlink
The change doesn't affect a big part of the Python ecosystem.
We aim to prevent such situation from happening by increasing the
robustness of the python-rpm-generators (namely
[https://src.fedoraproject.org/rpms/python-rpm-generators/blob/rawhide/f/p...
pythondistdeps.py]).
The generator will error and fail the build if `python3dist(...) = 0`
was to be generated.
Based on discussion on python-devel mailing list there will be no way
to opt out from this change. There will be no possibility to package a
Python package with version `0`.
Packagers who encounter such need are encouraged to work with upstream
to set the version to at least `0.0.1`.
== Feedback ==
The idea was posted on
[https://lists.fedoraproject.org/archives/list/python-devel@lists.fedorapr...
python-devel mailing list] and received a positive feedback. No
alternatives to this approach were proposed.
== Benefit to Fedora ==
The correct metadata is essential for the whole package ecosystem.
More deterministic behavior of the generators will bring those
benefits:
* The packages will stop lying about the version they provide.
* The requirements generators (eg. `%pyproject_buildrequires`) will
correctly evaluate the Build- and Runtime Requirements based on the
correct Provides.
* The package maintainers who BuildRequire `%{py3dist pkgname} >= 0.2`
in their specfiles will always require the correctly evaluated
version.
== Scope ==
* Proposal owners:
# implement & test the change in python-rpm-generators
([https://src.fedoraproject.org/rpms/python-rpm-generators/blob/rawhide/f/p...
pythondistdeps.py])
* Other developers:
** Fix the packaging error to generate correct metadata and successful
build. There's no common way to deal with such packages. In most of
the cases the issue originates from packaging errors that need to be
fixed. Contact the change owners if you need help with the necessary
changes to your package.
* Release engineering: not needed for this Change
* Policies and guidelines:
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_source...
Python Packaging Guidelines] cover the topic of creating the version
string. This will be valid even when we change the Python RPM
generators behavior
* Trademark approval: not needed for this Change
* Alignment with Objectives: No
== Upgrade/compatibility impact ==
None.
== How To Test ==
* Prepare a Python package, set the version to `0`
or
* Use one of the known packages that provide version `0`.
* Try to build an RPM package in a regular way (eg. mockbuild)
* The build should fail.
== User Experience ==
The actual users should notice no difference.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: Revert
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
This page is the documentation of this change.
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 4 months
F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite
(Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd
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 ==
By design, ostree does not manage bootloader updates as they can not
(yet) happen in a transactional, atomic and safe fashion. Thus bootupd
(https://github.com/coreos/bootupd) was created to solve this issue
and enable admin-lead bootloader updates. This change is about
enabling bootupd integration in Fedora Silverblue and Fedora Kinoite
to make bootloader updates easier.
== Owner ==
* [[User:Siosm| Timothée Ravier]] <siosm(a)fedoraproject.org>
* [[User:Tpopela| Tomáš Popela]] <tpopela(a)fedoraproject.org>
* [[User:Walters| Colin Walters]] <walters(a)fedoraproject.org>
== Detailed Description ==
Adding bootupd full bootupd support has two immediate benefits:
* User will be able to easily update the bootloader on their system.
This will let them apply Secure Boot dbx updates that block old
bootloaders with known vulnerabilities from loading. See:
** https://github.com/fedora-silverblue/issue-tracker/issues/355
** https://bugzilla.redhat.com/show_bug.cgi?id=2127995
* We can start planning for the removal of the ostree-grub2 package
from the images to solve the "all deployments are shown twice in GRUB"
issue. This bug comes from the fact that old GRUB versions that do not
have BLS support and we thus can not only rely on BLS support in
ostree to generate boot and have to also update the grub configuration
for every updates via the scripts in the ostree-grub2 package. This
has already (indirectly) caused a major upgrade issue on
Silverblue/Kinoite requiring manual interventions from all users. See:
** https://fedoramagazine.org/manual-action-required-to-update-fedora-silver...
** https://github.com/fedora-silverblue/issue-tracker/issues/120
Note that we can not yet enable unattended bootloader updates as even
though bootupd tries hard hard to make those updates as safe as
possible, it is currently not possible that they are safe if the
system crashes (or loses power) at the wrong time. The following
change in shim (https://github.com/rhboot/shim/pull/502) should help
with that.
Thus bootloaders updates will remain a manually user triggered
operation for now.
Also note that this change currently relies on the image being
composed via rpm-ostree in unified core, which is the subject of the
following change also proposed for Fedora 38:
https://fedoraproject.org/wiki/Changes/FedoraSilverblueUnifiedCore
== Feedback ==
None so far.
<!-- Summarize the feedback from the community and address why you
chose not to accept proposed alternatives. This section is optional
for all change proposals but is strongly suggested. Incorporating
feedback here as it is raised gives FESCo a clearer view of your
proposal and leaves a good record for the future. If you get no
feedback, that is useful to note in this section as well. For
innovative or possibly controversial ideas, consider collecting
feedback before you file the change proposal. -->
== Benefit to Fedora ==
Fedora Silverblue and Fedora Kinoite users can easily do bootloaders
updates (that includes security fixes) and we can remove support for
legacy GRUB versions thus simplify the upgrade process and making it
more reliable.
== Scope ==
* Proposal owners: Testing of the integration and new builds. The code
changes are mostly done and the integration changes are mostly already
ready as bootupd has already been integrated in a similar fashion in
Fedora CoreOS.
* 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 Objectives: N/A
== Upgrade/compatibility impact ==
There should be not visible change for users when upgrading. The
change only impacts the way the images are composed on the server.
== How To Test ==
We will extend the test instructions once the unified core changes
have landed. You can follow:
https://github.com/fedora-silverblue/issue-tracker/issues/120 and
https://github.com/fedora-silverblue/issue-tracker/issues/355.
== User Experience ==
For now, users will have to update their bootloader manually via the
command line. Integration to GNOME Software and Plasma Discover might
be interesting to make that easier.
Once the fallback EFI feature is available in shim (and support
implemented in bootupd), we can consider implementing automated
updates.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Revert the change in the rpm-ostree
manifests. Owners will do it. Nothing to do for users.
* Contingency deadline: Can happen anytime.
* Blocks release? No
== Documentation ==
We will write docs to let users update their bootloaders manually.
They will look very similar to
https://docs.fedoraproject.org/en-US/fedora-coreos/bootloader-updates/.
== Release Notes ==
Will have to be written.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 4 months
F38 proposal: Build Fedora Silverblue & Kinoite using rpm-ostree
unified core mode (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/FedoraSilverblueUnifiedCore
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 ==
rpm-ostree upstream development is focusing on the "unified core" mode
and the previous mode is being deprecated. Fedora Silverblue and
Fedora Kinoite are currently building using the old mode and we've
wanted to move over for a while. The main advantage of the unified
core mode is that it is stricter and safer, while enabling some post
processing steps to happen during or after the image build.
== Owner ==
* Name: [[User:Siosm| Timothée Ravier]], [[User:Tpopela| Tomáš
Popela]], [[User:Walters| Colin Walters]]
* Email: <siosm(a)fedoraproject.org>. <tpopela(a)fedoraproject.org>,
<walters(a)fedoraproject.org>
== Detailed Description ==
For more details about the difference between the two mode, you can
read the upstream issue:
https://github.com/coreos/rpm-ostree/issues/729. See also the history
in https://pagure.io/workstation-ostree-config/issue/137.
On top of the advantages listed above, we need unified core support to
be able to add bootupd integration to Fedora Silverblue & Kinoite.
See:
* https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd
* https://github.com/fedora-silverblue/issue-tracker/issues/120
* https://pagure.io/workstation-ostree-config/pull-request/313
The in-progress changes are in:
* Support in Pungi: https://pagure.io/pungi/pull-request/1626 &
https://pagure.io/pungi/pull-request/1629
* Fedora Pungi configuration change:
https://pagure.io/pungi-fedora/pull-request/1115
* Fedora Silverblue & Kinoite changes in progress in:
https://pagure.io/workstation-ostree-config/pull-request/296
GitHub issue used to track this work and testing:
https://github.com/fedora-silverblue/issue-tracker/issues/333
== Feedback ==
None yet.
<!-- Summarize the feedback from the community and address why you
chose not to accept proposed alternatives. This section is optional
for all change proposals but is strongly suggested. Incorporating
feedback here as it is raised gives FESCo a clearer view of your
proposal and leaves a good record for the future. If you get no
feedback, that is useful to note in this section as well. For
innovative or possibly controversial ideas, consider collecting
feedback before you file the change proposal. -->
== Benefit to Fedora ==
The old mode in rpm-ostree is not maintained anymore and less tested
thus more prone to bugs. Moving to the new mode will unify Silverblue
& Kinoite to the same code that is used to build Fedora CoreOS and
that receives a lot of testing. This will remove maintenance burden on
the rpm-ostree project as they will thus be able to remove the old
code. The new mode also makes composes work the same on the server
side and the client side and makes them safer by more strictly
confining scriptlets execution.
== Scope ==
* Proposal owners: Testing of builds with the new mode to make sure
there is not regression. The infra & configurations changes for Pungi
should be ready.
* 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 Objectives: N/A
== Upgrade/compatibility impact ==
There should be not visible change for users when upgrading. The
change only impacts the way the images are composed on the server.
== How To Test ==
Use the commands from the justfile in
https://pagure.io/workstation-ostree-config/pull-request/296 to test
building in unified core mode. Update an existing installation and
verify that everything works as expected. Once we merge that in
Rawhide, updating will be enough (no need to rebuild).
== User Experience ==
N/A
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Revert to non unified core build mode (single
change in Fedora's Pungi configuration). Owners will do it. Nothing to
do for users.
* Contingency deadline: Can happen anytime.
* Blocks release? No
== Documentation ==
N/A
== Release Notes ==
N/A
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 4 months
F38 proposal: Perl: Replace versioned MODULE_COMPAT_ requires by
macro (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Perl_replace_MODULE_COMPAT_by_macro
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 ==
A ''perl(:MODULE_COMPAT_%(eval "<nowiki>`%{__perl}
-V:version`</nowiki>"; echo $version))'' run-time dependency will be
replaced with a new ''%perl_require_compat'' macro in all Perl spec
files.
The macro will expand differently based on architecture specificity of
the binary packages. That will significantly shrink an amount of Perl
packages required to be rebuilt with each Perl upgrade.
== Owner ==
* Name: [[User:jplesnik| Jitka Plesnikova]]
* Email: <jplesnik(a)redhat.com>
=== Completed items ===
=== Items in progress ===
* Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F38
* Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F37
* Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F36
* Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F35
* Add `%perl_require_compat` macro to ''perl-srpm-macros'' in RHEL 9
* Update [[Packaging:Perl | Fedora Packaging Guidelines for Perl]]
* Replace ''perl(:MODULE_COMPAT_XXX)'' by `%perl_require_compat`
run-time in all F38 spec files (3259)
== Detailed Description ==
The list of packages that need to be rebuilt with the new major
version of Perl is determined according to the dependency on
''perl(:MODULE_COMPAT_XXX)'' now.
In Fedora, all Perl modules run-require the versioned
''perl(:MODULE_COMPAT_XXX)'' provided by ''perl-libs'' now.
However, only multi-arch packages need to have a dependency on the
particular version of Perl it was built against, or on a newer version
of Perl that provides backward compatibility with it. For those
packages, we need to ensure that the packages will use the right
version of ''libperl.so'' for the Perl used during the rebuild.
The noarch packages don't need to be rebuilt against each new major
version of Perl, they only have to require non-versioned ''perl-libs''
which includes all directories used by all Perl modules.
The macro ''%perl_require_compat'' will evaluate the run-require based
on ''%{_target_cpu}''. The macro will be defined in the rpm
''perl-srpm-macros'' and the definition is:
`%perl_require_compat %[ "%{_target_cpu}" == "noarch" ? "perl-libs" :
"%{!?perl_version:perl-libs}%{?perl_version:perl(:MODULE_COMPAT_%{perl_version})}"
]`
The macro ''%perl_requires_compat'' will evaluate to the correct
value. There is a known, yet harmless, imperfection: The macro will
evaluate to ''perl(:MODULE_COMPAT_XXX)'' even in noarch subpackages of
a multi-arch main package. In this case, I recommend to use `Requires:
%perl_require_compat`. The purpose of the change is a matter of
simplifying the rebuild, where it depends if the source package
produces at least one multi-arch binary package. Not on whether it
makes a noarch subpackage next to it.
If you don't want to see this imperfection you could use directly
`Requires: perl-libs`.
The macro will work for all supported Fedoras and EPEL 9.
For EPEL 8 and older, it won't work, because the
[https://rpm-software-management.github.io/rpm/manual/macros.html
Expression Expansion] is not implemented there. In these versions,
''perl(:MODULE_COMPAT_%(eval "<nowiki>`%{__perl}
-V:version`</nowiki>"; echo $version))'' must be used.
== Benefit to Fedora ==
It will simplify the rebuild and reduce the number of packages which
have to be rebuild from 3259 to approximately 600. It should currently
be enough to rebuild only multi-arch packages and those that are part
of the Perl itself (dual-life packages). Here we need to ensure that
the packages will use the right ''libperl.so'' for the Perl used. The
new syntax will also be shorter and clearer for packagers.
== Scope ==
* Proposal owners:
** Submit Fedora Packaging Guidelines for Perl update to Fedora
Packaging Committee.
** Update and rebuild perl-srpm-macros source package.
** Add ''%perl_require_compat'' to ''perl-srpm-macros'' package in
older Fedoras.
** Replace Requires for ''perl(:MODULE_COMPAT_XXX)'' with
''%perl_require_compat'' in all spec files.
* Other developers: Get familiar with new Fedora Packaging Guidelines for Perl.
* Release engineering: No action needed.
[https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED
FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: N/A (not needed for this Change) <!--
REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Do the packaging guidelines or other documents need to be updated
for this feature? If so, does it need to happen before or after the
implementation is done? If a FPC ticket exists, add a link here.
Please submit a pull request with the proposed changes before
submitting your Change proposal. -->
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
N/A
== How To Test ==
All multi-arch packages which use the macro should run-require
''perl(:MODULE_COMPAT_%{perl_version})'' and the ''noarch'' packages
should run-require ''perl-libs'' except the case listed in '''Detailed
Description'''.
== User Experience ==
There should not be any remarkable change in user experience.
== Dependencies ==
This change will affect 3259 source packages and all binary noarch
packages. The rebuild of affected packages will be done by mass
rebuild of Fedora 38. There is no dependency on other Fedora changes.
== Contingency Plan ==
* Contingency mechanism: The change will be reverted.
* Contingency deadline: Before Mass Rebuild.
* Blocks release? No.
== Documentation ==
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 4 months
F38 proposal: MobilityPhoshImage (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/MobilityPhoshImage
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 ==
Phosh is a wayland shell for mobile devices based on Gnome. The
mobility SIG has packaged up Phosh and related packages into a
'phosh-desktop' package group and would like to start making x86_64
and aarch64 images for mobile devices.
== Owner ==
* Name: [[User:Kevin| Kevin Fenzi]], [[User:Torbuntu| Torrey Sorensen]]
== Detailed Description ==
There's a number of x86_64 and aarch64 tablets and other mobile
devices that could use a more mobile centric interface/desktop than
traditional Fedora desktops/labs/spins. Having Fedora images for these
devices will make it easier to install and use them. Having a image
will also help remix efforts, allowing them to reuse userspace
packages and metadata (kickstarts, etc) with a modified kernel.
Note: Plasma Mobile is also being packaged and will be requested in
another change
Note: Pinephone and Pinephone Pro are eventual targets for these
images, but more kernel patches must be upstreamed before these
devices will boot and function.
== Benefit to Fedora ==
These images will spread Fedora to mobile devices and bring more users
into the Fedora community as well as showcasing upstream work to
provide a 100% open source phone interface for devices once they are
workable from vanilla kernels.
== Scope ==
* Proposal owners: Create kickstarts and other configuration needed to
produce aarch64 and x86_64 images. Fix bugs related to phosh-desktop
group and associated packages.
* Other developers: Help test images and groups
* Release engineering: Review kickstarts and pungi configutation,
produce images.
* 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 ==
== How To Test ==
Install the produced image to a suitable x86_64 or aarch64 device with
arm-image-installer or dd
Boot the image and confirm it comes up to a phosh desktop
Use various desktop functions and report issues.
== User Experience ==
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), Yes/No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Initial images are produced for x86_64 and aarch64 mobile devices
using the Phosh desktop.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 4 months
F38 proposal: Ruby 3.2 (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Ruby_3.2
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 ==
Ruby 3.2 is the latest stable version of Ruby. Many new features and
improvements are included for the increasingly diverse and expanding
demands for Ruby. With this major update from Ruby 3.1 in Fedora 37 to
Ruby 3.2 in Fedora 38, Fedora becomes the superior Ruby development
platform.
== Owner ==
* Name: [[User:vondruch| Vít Ondruch]]
* Email: vondruch(a)redhat.com
== Detailed Description ==
Ruby 3.1 is upstream's new major release of Ruby. Many new features
and improvements are included.
=== WASI based WebAssembly support ===
This is an initial port of WASI based WebAssembly support. This
enables a CRuby binary to be available on Web browser, Serverless Edge
environment, and other WebAssembly/WASI embedders. Currently this port
passes basic and bootstrap test suites not using Thread API.
=== Regexp timeout ===
A timeout feature for Regexp matching is introduced.
It is known that Regexp matching may take unexpectedly long. If your
code attempts to match an possibly inefficient Regexp against an
untrusted input, an attacker may exploit it for efficient Denial of
Service (so-called Regular expression DoS, or ReDoS).
The risk of DoS can be prevented or significantly mitigated by
configuring `Regexp.timeout` according to the requirements of your
Ruby application. Please try it out in your application and welcome
your feedback.
=== Other Notable New Features ===
* Language
** Anonymous rest and keyword rest arguments can now be passed as
arguments, instead of just used in method parameters.
** A proc that accepts a single positional argument and keywords will
no longer autosplat.
** Constant assignment evaluation order for constants set on explicit
objects has been made consistent with single attribute assignment
evaluation order.
** Find pattern is no longer experimental.
** Methods taking a rest parameter and wishing to delegate keyword
arguments through `foo(*args)` must now be marked with
`ruby2_keywords`
* Performance improvements
** YJIT
*** Support arm64 / aarch64 on UNIX platforms.
*** Building YJIT requires Rust 1.58.1+.
=== Other notable changes since 3.1 ===
* Hash
** Hash#shift now always returns nil if the hash is empty, instead of
returning the default value or calling the default proc.
* MatchData
** MatchData#byteoffset has been added.
* Module
** Module.used_refinements has been added.
** Module#refinements has been added.
** Module#const_added has been added.
* Proc
** Proc#dup returns an instance of subclass.
** Proc#parameters now accepts lambda keyword.
* Refinement
** Refinement#refined_class has been added.
* Set
** Set is now available as a builtin class without the need for
`require "set"`. It is currently autoloaded via the `Set` constant or
a call to `Enumerable#to_set`.
* String
** String#byteindex and String#byterindex have been added.
** Update Unicode to Version 14.0.0 and Emoji Version 14.0. (also
applies to Regexp)
** String#bytesplice has been added.
* Struct
** A Struct class can also be initialized with keyword arguments
without `keyword_init: true` on `Struct.new`
=== Compatibility issues ===
* Removed constants
** `Fixnum` and `Bignum`
** `Random::DEFAULT`
** `Struct::Group`
** `Struct::Passwd`
* Removed methods
** `Dir.exists?`
** `File.exists?`
** `Kernel#=~`
** `Kernel#taint`, `Kernel#untaint`, `Kernel#tainted?`
** `Kernel#trust`, `Kernel#untrust`, `Kernel#untrusted?`
=== C API updates ===
* Removed C APIs
** `rb_cData` variable.
** "taintedness" and "trustedness" functions.
== Benefit to Fedora ==
With a latest release, Ruby language is supporting the newest language
features, which enables even faster and easier development of Ruby
applications.
== Scope ==
* Proposal owners:
** Finish packaging of Ruby 3.2. Current changes available in PR
https://src.fedoraproject.org/rpms/ruby/pull-request/134
** Rebuilding of Ruby packages providing native extensions (i.e.
packages which depends on libruby).
* Other developers:
** Rebuild of packages with binary extensions (i.e. packages which
depends on libruby) will be handled automatically, but some packages
might need fixes/updates to support Ruby 3.2 properly.
* Release engineering: [https://pagure.io/releng/issues/11115 #11115]
** The packages are going to be rebuild in side-tag, but that does not
need releng involvement nowadays.
* 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 ==
* User specific Ruby binary extensions need to be rebuild.
* Ruby packages/application dependencies might need to be adjusted if
newly bundled gems are used.
== How To Test ==
* No special hardware is needed.
* To test, install Ruby 3.2. The test builds are published in PR or on
Ruby-SIG ML
* Try to locally rebuild your packages using Ruby 3.2.
* Use the packages with your applications previously written in Ruby.
* If something doesn't work as it should, let us know.
== User Experience ==
The Ruby programs/scripts should behave as they were used to.
== Dependencies ==
<!-- What other packages (RPMs) depend on this package? Are there
changes outside the developers' control on which completion of this
change depends? In other words, completion of another change owned by
someone else and might cause you to not be able to finish on time or
that you would need to coordinate? Other upstream projects like the
kernel (if this is not a kernel change)? -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<pre>
$ dnf repoquery --disablerepo=* --enablerepo=rawhide
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' |
sort | uniq | wc -l
130
</pre>
== Contingency Plan ==
* Contingency mechanism: We would like to get a special buildroot tag
to be able to rebuild necessary the packages with Ruby 3.2. If
anything goes wrong, the tag could be easily dropped and previous
version of Ruby 3.1 and its dependencies stays intact. The tag would
be merged into F38 after everything is rebuild
* Contingency deadline: Mass Rebuild
* Blocks release? No
== Documentation ==
* [http://www.ruby-doc.org/ Help and documentation for the Ruby
programming language]
* [https://github.com/ruby/ruby/blob/master/NEWS.md Ruby 3.2.0 NEWS]
* [https://www.ruby-lang.org/en/news/2022/09/09/ruby-3-2-0-preview2-released/
Ruby 3.2 Preview 2 release announcement]
== Release Notes ==
* The Ruby 3.2 bumps soname, therefore Ruby packages, which use binary
extensions, should be rebuilt. Nevertheless, since upstream paid great
attention to source compatibility, no changes to your code are needed.
https://github.com/ruby/ruby/blob/master/NEWS.md
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 4 months