F45 Change Proposal: Versioned libgit2 packages [SystemWide]

Project Discussion Change Proposals
, ,
1

Versioned libgit2 packages

Wiki

Announced

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 :open_book:

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 :open_book:

  • Name: [[User:Decathorpe| Fabio Valentini]]
  • Email: decathorpe AT gmail DOT com

Detailed Description :open_book:

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 :open_book:

N/Y

Benefit to Fedora :open_book:

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 :open_book:

  • 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: [Making sure you're not a bot! #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 :open_book:

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) :open_book:

N/A

Do you require ‘QA Blueprint’ support? Y/N

How To Test :open_book:

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 :open_book:

No impact to user experience is expected.

Dependencies :open_book:

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 :open_book:

  • 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 :open_book:

N/A

Release Notes :open_book:

\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.

Last edited by @alking 2026-04-29T12:43:29Z

Last edited by @alking 2026-04-29T12:43:29Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

Will there need to be two -devel packages?
If there’s a -devel package only for the latest version, how does this proposal fit with the idea of ​​reproducible builds?
The idea of ​​packaging lib%name%abiversion or lib%name%soversion instead of just lib%name isn’t new. This is certainly used for most libraries in ALT Linux and, as far as I know, in OpenSUSE.
Personally, I think this is a bad idea, because this packaging method might be suitable for simple libraries like libgit2, which only contain shared libraries and developer files. But for complex libraries with many files, this turns into a quest for packaging so that both versions can be installed side-by-side on the system. This is especially bad when upstream doesn’t want to support this.

And again, in my opinion, the repository ends up being “messier,” because we either build two versions of -devel packages and specify conflicts in them, or only one -devel version, resulting in a library without developer files. Also, library clients are starting to diverge between these two libraries with different ABIs.
I think this approach has more downsides, especially if it starts to spread to a larger number of packages.
But that’s just my humble opinion.

4

Yes, that is the intention, and the usual approach when providing two different versions of a library. This also is already the case, libgit2-devel and libgit2_1.8-devel both exist.

This is not the case. -devel packages will continue to be provided for all versions (and yes, they will conflict with each other). This is also already the status quo, nothing changes (apart from the package names).

What makes you think that this approach will spread? It’s a proposal for one package, where multiple parallel-installable versions are already available - this would just be simplifying the package names and ensure that dependent packages explicitly build against the version they support, not just the one that happens to be the “latest” one.

1 Like
5

Okay. Thanks for the clarification. I used another distribution where this approach was common. That’s why I always get nervous when this topic is discussed.

1 Like
6

This feels like a bit of a dangerous precedent, for this one ostensibly-minor package. Every library in our repos could be packaged like this, and in the past we’ve always been very deliberately reticent about this sort of thing because it can very quickly get out of hand. For instance,

…How does that work, with the multiple libgit2 version packages? Would we then need python3-pygit2_1.8, python3-pygit2_1.9, etc? (That’s a leading question, because we can’t do that. There’s no way for them to share the /usr/lib64/python3.14/site-packages/pygit2/ install directory, so it’s not possible to break up the Python packaging that way.) I assume what’s being proposed is that a new libgit2 version can be installed while pygit2 still depends on the previous version, until it’s ready to be updated to a version that’s compatible with the newer libgit2.

In the past when this sort of thing has been supported, it’s typically been done using -compat packages. (Or compat- packages, at some point things seem to have been flipped around so now there’s compat-ffmpeg41 and compat-lua-libs-5.1.5, but also sdl12-compat and libusb-compat-0.1.) If nothing else, the compat label (wherever it ends up getting slapped on) serves as a signifier that the library version in question is a legacy package that should be moved off of if at all possible, and as soon as reasonably achievable.

Is there a reason that introducing a compat-libgit2_1.8 or libgit2-compat1.8 package alongside libgit2-1.9 isn’t sufficient to address the versioning issue, but in a way that makes it abundantly clear that the older release is… well… older, and discouraged for use unless it’s really necessary?

My chief worry is that once libgit2_1.8 is out there and packages depend on it, they’ll ALWAYS depend on it, and never migrate to libgit2_1.9 or libgit2_2 or whatever comes after. Even when they could!2

If a package is fully compatible with the new ABI, but still retains support for the legacy one as well, there’s little motivation for a packager to rock the boat by changing its dependency from libgit2_1.8 to libgit2_1.9. Which, in my experience, means they’re unlikely to do so unless they’re forced to. Inertia is probably the major driving factor behind our packaging ecosystem’s retention of legacy packages.

Notes

  1. (Oops, compat-ffmpeg4 is rpmfusion, not Fedora, so ignore that.)
  2. If you want evidence that this is a real concern, go look into the history of packages depending on Qt. When do/did packages typically make the jump from Qt5 to Qt6? Is it when they release a version that introduces support for Qt6? NOPE. The majority of the time, it only happens when they release a version that drops support for Qt5, and no sooner.
7

[citation needed]

That’s precisely the reason for concern, though. Packages building against the latest release of a dependency — by default, unless explicitly and exceptionally configured to do otherwise — is generally seen as a feature, not a bug.

8

Conflicting -devel packages are kind of a problem, though.

  1. From an enduser standpoint , it makes local builds harder. If I’m a Fedora user who wants to do a local build of some package that depends on libgit2_1.8, finding out that I have to uninstall libgit2_1.9-devel in order to do so is a hassle.
  2. Even on a build system, it’s not a problem until you end up with a package that depends on something built against libgit2_1.8 and something built against libgit2_1.9. You’re in for a world of hurt if installing both of those dependencies’ -devel packages ends up trying to pull in knock-on dependencies of libgit2_1.9-devel and libgit2_1.8-devel at the same time.

With compat packages, typically they’re set up so that their -devel packages don’t conflict. Consider libusb1-devel vs. libusb-compat-0.1-devel:

$ sudo dnf repoquery -l libusb1-devel.x86_64
Updating and loading repositories:
Repositories loaded.
/usr/include/libusb-1.0
/usr/include/libusb-1.0/libusb.h
/usr/lib64/libusb-1.0.so
/usr/lib64/pkgconfig/libusb-1.0.pc

$ sudo dnf repoquery -l libusb-compat-0.1-devel.x86_64
Updating and loading repositories:
Repositories loaded.
/usr/bin/libusb-config
/usr/include/usb.h
/usr/lib64/libusb.so
/usr/lib64/pkgconfig/libusb.pc

That may take some adjustment at package-build time, to customize directory names and etc., but since packaging typically relies on pkg-config or /usr/lib64/cmake/ configuration files (I see that libgit2 provides both), as long as the custom paths are encoded into that configuration system the dependencies will get it right — although they may have to be patched to use alternate identifiers for the legacy package (find_package(libgit2_1.8) instead of find_package(libgit2) in CMake, for example). And if upstream is really being so messy about ABI versioning, they may even be amenable to upstreaming versioned, non-conflicting install locations for their development files as well.

Seems like the least they could do.

9

The only change regarding python-pygit2 package will be that it will depend on one specific libgit2 package version, not just “the latest” (which should prevent issues caused by mismatches between libgit2 and python-pygit2 versions, which has caused problems in the past).

The compat-* naming convention was dropped from the Packaging Guidelines. Adding the version suffix is the correct way to handle this now.

Yes, this will require package changes to move to new versions. This is an intentional part of the Change proposal, because blindly updating to a new version can cause issues due to API, ABI, or behaviour changes. Packages should move to new libgit2 versions intentionally and only when it’s known that doing so is safe.

I have some experience dealing with this in the Rust ecosystem. We routinely prune “compat” packages for old versions of libraries, and actively port things to new versions. I had planned to handle the gradual transition from old to new libgit2 versions similarly, and eventually retire the old versions when they’re no longer needed. If a bigger stick is needed, I can file “Change Proposal: Retire libgit2_1.8” …

Are you implying that there’s more to the proposal than meets the eye? If you don’t trust my intentions, then I’m not sure anything I can say here would convince you otherwise.

In general, I would agree, though the past has shown that this is problematic when it comes to libgit2.

10

The fact that they conflict is a good thing, IMO. It makes it obvious that a package you’re building pulls in two conflicting versions, and it gives you a dependency resolution error (rather than obscure build or linker errors).

As I said above, this is a red herring. The Package Naming Guidelines explicitly state to use the version suffix for the source package name. Using “compat” in the package name is no longer allowed.

11

I have some experience dealing with this in the Rust ecosystem.

As far as I know, Rust crates are only built statically, so there’s no need to maintain multiple library versions because they’re compiled into the binary.
Does it make sense to build libgit2-*-devel-static for problematic packages?

12

It sounds like you’re confusing different things here. Yes, Rust libraries get statically built and linked together, but that doesn’t mean we don’t have to provide different parallel-installable versions of some libraries.

1 Like
13

I’m strongly in favor of this proposal.

The concerns I see raised so far seem to also apply to the existing libgit2_1.8 and libgit2 combination, as well as many other libraries with compat combinations. Nothing gets worse by effectively renaming libgit2 to libgit2_1.9, things are just more explicit and safer.

The benefits of this are exciting to me.

  • It allows dependent packages to migrate to new libgit2_* versions on their schedule (or rather, their upstreams’ schedules), instead of being disruptively forced to do it all at the same time.
  • It makes it easier to introduce new libgit2_* packages in stable Fedora and EPEL releases, not just in Rawhide. This is especially important for EPEL with its longer lifecycle.
  • It protects against koji buildroot breakage (rpmautospec) due to libgit2 changes.
  • It makes it easier to bootstrap new major versions of EPEL.

Most library packages don’t need a setup like this. Library packages that routinely have to create compat packages should consider switching to a structure like this, IMO.

1 Like