Wiki: https://fedoraproject.org/wiki/Changes/Versioned_libgit2_packages
Discussion Thread: https://discussion.fedoraproject.org/t/189891
**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 ==
Going forward, only fully versioned packages for libgit2 will be provided.
Dependent libraries and applications are adapted to build and link with the
specific libgit2 version they support, and the version-less package names
will no longer be provided.
== Owner ==
* Name: [[User:Decathorpe| Fabio Valentini]]
* Email: decathorpe AT gmail DOT com
== Detailed Description ==
Both major and minor versions of libgit2 bring ABI and / or API changes, so
applications and libraries that link libgit2 need to be rebuilt for new
versions. Using fully versioned package names (or version ranges on
pkgconfig dependency specs), packages are adapted to build with the
specific libgit2 version they support.
By providing fully versioned package names, it will be possible to
introduce newer libgit2 versions to older Fedora releases (and eventually
EPEL) transparently and without breaking existing dependencies. As
applications are adpated to new libgit2 versions, the oldest provided
versions will eventually become unused and can be dropped from Fedora.
* libgit2 (currently v1.9 in Fedora): will be retired
* libgit2_1.9: newly introduced, obsoleting the unversioned package names
* libgit2_1.8: already exists
When libgit2 v2.0.0 is released, it will be packaged as either
`libgit2_2.0` or `libgit2_2`, depending on whether libgit2 upstream can
finally commit to avoiding ABI changes in minor versions or not.
It is planned to eventually make equivalent changes in EPEL 10 and 9 in
order to be able to introduce new parallel-installable libgit2 versions
there too.
== Feedback ==
N/Y
== Benefit to Fedora ==
Historically, updates for libgit2 have been tricky due to handle due to
frequent ABI changes even in minor versions. Applications that built and
worked fine with one version of libgit2 might be subtly broken when built
with a different minor version. The corresponding Python bindings
(python-pygit2) and bindings for other languages would need to be updated
at the same time to avoid even more subtle breakage. Since core build
system components like rpmautospec utilize pygit2, issues quickly had a
large impact.
By providing fully versioned and parallel-installable packages for
different libgit2 versions by default in the future, dependent libraries,
applications, and language bindings can be explicitly moved to the next
version when things are ready and tested. It also allows introducing newer
versions of libgit2 - which often contain fixes for security issues - to
older Fedora releases (and eventually, EPEL) transparently without breaking
dependent packages.
== Scope ==
* Proposal owners:
Import new libgit2_1.9 package, providing libgit2 v1.9.
Adapt package dependencies to move away from unversioned dependencies.
Retire unversioned libgit2 package from Fedora Rawhide / 45+.
* Other developers:
Adapt package dependencies to move away from unversioned dependencies.
Pull requests for packages where the Change owner is not a co-maintainer
will be provided by the Change owner(s).
* Release engineering: [
https://forge.fedoraproject.org/releng/tickets/issues/13325 #13325]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
On upgrade, existing installs will be migrated from unversioned libgit2
packages to the versioned equivalents (currently, that would be
libgit2_1.9). No actual impact for users is expected.
== Early Testing (Optional) ==
N/A
Do you require 'QA Blueprint' support? Y/N
== How To Test ==
Upgrading to Fedora 45 should remove the libgit2 package and transparently
replace it with libgit2_1.9. Packages built against libgit2 v1.9 should
depend on libgit2_1.9, and packages built against libgit2 v1.8 should
depend on libgit2_1.8, and both should be parallel-installable.
== User Experience ==
No impact to user experience is expected.
== Dependencies ==
**libgit2**:
* R-gert
* R-git2r
* foundry (libfoundry)
* geany-plugins (geany-plugins-git-changebar, geany-plugins-workbench)
* git-evtag
* gnome-builder
* gnuastro
* julia
* kicad
* kommit
* kup-backup
* libgit2-glib
* nix (nix-libs)
* python-pygit2 (python3-pygit2)
* python-rpmautospec (rpmautospec, python3-rpmautospec)
* rpm-git-tag-sort
* rubygem-rugged
* rust (cargo)
* siril
**libgit2-devel** only:
* calligra
* goose
* kf5-ktexteditor
* kf6-ktexteditor
* public-inbox
* ruyi
== Contingency Plan ==
* Contingency mechanism:
If dependent packages cannot be adapted in time, retirement of the
unversioned libgit2 package can be postponed to a later release. The
package adaptations themselves are backwards compatible and do not need to
be reverted.
* Contingency deadline:
Final Freeze
* Blocks release?
No
== Documentation ==
N/A
== Release Notes ==
\nDifferent libgit2 minor versions will all be provided as fully-versioned,
parallel-installable packages in order to ensure easy upgrades and
migration paths for dependent applications, libraries, and language
bindings. The un-versioned libgit2 packages (libgit2, libgit2-devel) were
dropped.
Wiki: https://fedoraproject.org/wiki/Changes/RelocateRpmRepoConfigsToUsr
Discussion Thread: https://discussion.fedoraproject.org/t/188916
**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 ==
Relocate all packaged RPM repository configuration data from
<code>/etc</code> to <code>/usr</code>.
== Owner ==
* Name: [[User:Ngompa| Neal Gompa]]
* Email: ngompa13(a)gmail.com
== Detailed Description ==
This Change aims relocate all packaged RPM repository configuration data
from <code>/etc/yum.repos.d</code> to <code>/usr/share/dnf5/repos.d</code>.
All Fedora packaging PGP/GPG keys in <code>fedora-gpg-keys</code> will also
be relocated to <code>/usr/share/pki/rpm-gpg</code>.
This is now possible because all major read+write frontends for DNF
configuration now go through DNF5. Fedora has now switched to DNF version 5
in the build system ([[Changes/BuildWithDNF5|Fedora Linux 40]]), the
user-facing CLI tools ([[Changes/SwitchToDnf5|Fedora Linux 41]]), the
installer ([[Changes/Switch_Anaconda_installer_to_DNF5|Fedora Linux 43]]),
and PackageKit ([[Changes/PackageKit-DNF5|Fedora Linux 44]]). This means
all the major supported entry points implicitly support DNF5's layered
configuration system.
The <code>fedora-third-party</code> tool used by Fedora KDE Plasma variants
and Fedora Workstation will also be adjusted for this new world.
== Feedback ==
== Benefit to Fedora ==
The key benefit for Fedora is it establishes a clean separation of packaged
repository definitions and allows for users to trivially identify local
changes and undo them if desired. This is also necessary to simplify how
derivatives handle repository definitions, since moving it to
<code>/usr</code> allows the middle layer for packaged repository
configuration overrides to function properly.
== Scope ==
* Proposal owners:
** {{package|fedora-repos}}: Relocate yum.repos.d and rpm-gpg data to new
locations in <code>/usr</code>
** {{package|fedora-workstation-repositories}}: Relocate yum.repos.d and
rpm-gpg data to new locations in <code>/usr</code>
** {{package|fedora-third-party}}: Update configuration editor code to
generate drop-in files in <code>/etc/dnf/repos.override.d</code>
* Other developers: N/A (not needed for this Change)
* Release engineering: [
https://forge.fedoraproject.org/releng/tickets/issues/13321 #13321]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Distribution provided RPM repository configuration files, if unmodified,
will cleanly move from <code>/etc</code> to <code>/usr</code>. If modified,
they will stay in place and override the configuration files shipped in
<code>/usr</code> entirely.
Going forward, packaged repository configuration will no longer be present
in <code>/etc</code>.
== Early Testing (Optional) ==
N/A
== How To Test ==
Once the changes are made in Rawhide, simply upgrade into them and interact
with the package manager normally.
== User Experience ==
There should be no substantially visible changes to the user experience.
== Dependencies ==
* {{package|fedora-repos}}
* {{package|fedora-workstation-repositories}}
* {{package|fedora-third-party}}
== Contingency Plan ==
* Contingency mechanism: Rollback and defer to the next release
* Contingency deadline: Final Freeze
* Blocks release? Yes
== Documentation ==
DNF5 documentation on the configuration system:
https://dnf5.readthedocs.io/en/latest/dnf5.conf.5.html
== Release Notes ==
Fedora Linux 45 now ships all distribution-provided configuration for the
DNF package manager in <code>/usr</code>, which makes it easier to identify
user-local changes in <code>/etc</code> separately from
distribution-provided configuration.
Wiki: https://fedoraproject.org/wiki/Changes/perl5.44
Discussion Thread: https://discussion.fedoraproject.org/t/188915
**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 ==
A new *Perl 5.44* version brings a lot of changes done over a year of
development. Perl 5.44 should be released on May 20 2026. See [
https://metacpan.org/release/BOOK/perl-5.43.10/view/pod/perldelta.pod
perldelta for 5.43.10 (devel release)] for more details about new release.
== Owner ==
* Name: [[User:Jplesnik| Jitka Plesníková]], [[User:Mspacek| Michal Josef
Špaček]]
* Email: <jplesnik(a)redhat.com>, <mspacek(a)redhat.com>
== Detailed Description ==
New Perl is released every year and updates containing mainly bug fixes
follow during the year. The 5.44.0 version is stable release this year.
== Feedback ==
N/A
== Benefit to Fedora ==
Up-to-date and latest perl release will be delivered to Fedora users.
== Scope ==
Every Perl package will be rebuilt in a dedicated *f45-perl* build-root
against perl 5.44.0 and then if no major problem emerges the packages will
be merged back to *f45* build-root.
* Proposal owners: New perl and all packages requiring *libperl.so* or
versioned *perl(MODULE_COMPAT)* will be rebuilt into *f45-perl* build-root.
* Other developers: Owners of packages that fail to rebuild, mainly
perl-sig users, will be asked using Bugzilla to fix or remove their
packages from the distribution.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number]
Release engineers will be asked for new *f45-perl* build-root inheriting
from *f45* build-root. After successful finishing the rebuild, they will be
asked to merge *f45-perl* packages back to *f45* build-root.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
Vast majority of functionality will be preserved. Only the packages that
failed to build against perl 5.44 will be removed from the distribution.
That will require to remove those packages from the existing systems
otherwise a package manager will encounter unsatisfied dependencies. The
developers in Perl language are advised to install *perl-doc* and
*perl-debugger* packages.
== Early Testing (Optional) ==
N/A
== How To Test ==
Try upgrading from Fedora 44 to 45. Try some Perl application to verify
they work as expected. Try embedded perl in [
https://src.fedoraproject.org/rpms/openldap slapd] or [
https://src.fedoraproject.org/rpms/net-snmp snmpd].
== User Experience ==
There should not be any remarkable change in user experience. With the
exception that previously locally installed modules with a CPAN clients
will need a reinstallation.
== Dependencies ==
There is more than 3500 packages depending on perl. We will rebuild only
all dual-lived packages and packages which require *libperl.so* or
versioned *perl(MODULE_COMPAT)*. It means only about 600 packages needs to
rebuild. Most of them are expected not to break. Finishing this change can
be endangered only by critical changes in a toolchain.
*noarch* packages don't need to be rebuilt now.
== Contingency Plan ==
* Contingency mechanism: If we find perl 5.44 is not suitable for Fedora
45, we will revert back to perl 5.42 and we drop the temporary build-root
with already rebuilt packages.
* Contingency deadline: branching Fedora 45 from Rawhide.
* Blocks release? No.
== Documentation ==
* [https://metacpan.org/release/BOOK/perl-5.43.10/view/pod/perldelta.pod
perldelta for 5.43.10]
* An announcement on perl-devel mailing list
* An announcement on fedora-devel mailing list
== Release Notes ==
Perl 5.44.0 is a new stable release that focuses on improving performance,
refining existing features, and adding new experimental capabilities.\n\nTBD
On Thu, 2026-04-16 at 21:25 +0000, Jef Spaleta via test-announce wrote:
> There will be a blocker review meeting on Monday April 22nd at 1900 UTC (1500 EDT) in #blocker-review on matrix.
Correction: Monday April 20th, at 1600 UTC.
> There will be a subsequent Go/No-Go meeting Thursday April 23th 1800 UTC (1400 EDT) (I'll get that updated in the published schedule
This is correct.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org
https://www.happyassassin.net
Due to outstanding blocker bugs F44 Final was declared NO-GO in today's Go/No-GO meeting.
The new release target date for Fedora 44 is now April 28th, 2026.
I've updated the Fedora schedule to reflect the decision of today's Go/No-Go meeting
https://fedorapeople.org/groups/schedule/f-44/f-44-key-tasks.html
There will be a blocker review meeting on Monday April 22nd at 1900 UTC (1500 EDT) in #blocker-review on matrix.
There will be a subsequent Go/No-Go meeting Thursday April 23th 1800 UTC (1400 EDT) (I'll get that updated in the published schedule soon)
Apologies if there are some other dates in the schedule that seem to be referencing the earlier target release date, I'll get that cleaned up as we find them.
-jef"Really looking forward to Aoife coming back from leave and wrangling the schedule"spaleta
Wiki: https://fedoraproject.org/wiki/Changes/Build_x86-64-v3_Packages
Discussion Thread: https://discussion.fedoraproject.org/t/187943
**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 ==
Build x86_64_v3 packages in addition to the current x86_64_v1 builds.
== Owner ==
* Name: [[User:lleyton| Lleyton Gray]], [[User:KyleGospo| Kyle
Gospodnetich]], [[User:owensz| Owen Zimmerman]]
* Email: lleyton(a)fyralabs.com, me(a)kylegospodneti.ch, owen(a)fyralabs.com
== Detailed Description ==
This change would introduce a new primary architecture, x86_64_v3. Existing
packages built for x86_64 would start being built for v3. The support for
installing x86_64 microarch packages are already in libsolv and RPM, but
will require changes in DNF and Koji.
== Feedback ==
No feedback at this moment.
== Benefit to Fedora ==
This change allows installing packages compiled against a more recent
x86_64 baseline, which can improve system performance for modern machines.
== Scope ==
* Proposal owners:
** Extend Koji to support x86_64 architecture levels
** Add compiler flag definitions for x86_64_v2/v3/v4 to `redhat-rpm-config`
** Add support to DNF5 to transparently use packages for higher levels as
appropriate
** Add support to Pungi for x86_64 architecture levels to x86_64 composes
* Other developers:
** Release Engineering: Enable and deliver x86_64_v3 repositories and
images for x86_64
* Release engineering: [
https://forge.fedoraproject.org/releng/tickets/issues/13310 #13310]
* Policies and guidelines: Packaging guidelines need to be updated to note
`%{x86_64}` should be used for architecture conditionals for x86_64 instead
of just the plain `x86_64`.
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: Building microarchitecture packages
for modern systems helps Fedora lead in distribution development. However,
this change does not align with any specific objective.
== Upgrade/compatibility impact ==
On upgrade, systems that have support for the x86_64_v3 baseline will
automatically install x86_64_v3 packages when available.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
To test, a x86_64 system supporting the v3 baseline is required. When
available, DNF will select packages with the highest compatible baseline.
Testing involves upgrading or installing 45 on a supported system, ensuring
that packages installed are compiled for the x86_64_v3 baseline, and
validating that packages built for v3 work as expected.
== User Experience ==
Packages compiled against a higher baseline may perform better on systems
which support it.
== Dependencies ==
koji, redhat-rpm-config, pungi, dnf5.
== Contingency Plan ==
* Contingency mechanism: Revert and unpublish x86_64_v3 packages and defer
to the next release.
* Contingency deadline: Beta Freeze
* Blocks release? No
== Documentation ==
There's no current upstream documentation for microarch handling in DNF,
but for reference, these PRs may be useful:
* https://github.com/rpm-software-management/rpm/pull/2315
* https://github.com/rpm-software-management/dnf5/pull/2591
* https://github.com/rpm-software-management/mock/pull/1733
== Release Notes ==
\n\n\nFedora now provides packages for the x86_64 v3 baseline. When
upgrading the system to Fedora 45, DNF will pull packages for x86_64 v3 if
the host system is detected as supporting a x86_64 v3 or higher baseline.
This may improve system performance on modern machines.