Bug 2446967

Summary: Should Eigen 5.* use a different component name, say eigen5?
Product: [Fedora] Fedora Reporter: Jan Pazdziora <adelton>
Component: eigen3Assignee: Sandro Mani <manisandro>
Status: CLOSED DEFERRED QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: laurent.rineau__fedora, manisandro
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2026-03-21 07:24:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jan Pazdziora 2026-03-12 15:46:45 UTC
Hello,

eigen3 was updated to 5.0.0 in Fedora 44 (also noted in https://bugzilla.redhat.com/show_bug.cgi?id=2404135). That means packages that need eigen3 in version 3.* are cut off from it in Fedora 44. Specifically in prusa-slicer, we now see

CMake Error at CMakeLists.txt:377 (find_package):
  Could not find a configuration file for package "Eigen3" that is compatible
  with requested version "3.3.7".
  The following configuration files were considered but not accepted:
    /usr/share/cmake/eigen3/Eigen3Config.cmake, version: 5.0.1
      The version found is not compatible with the version requested.

I assume Eigen project did the major version bump specifically to be able to break compatibility ties to 3.*. I also see that upstream Eigen 3.4.1 was released on September 30, 2025, the same day 5.0.0 was released.

Could or should eigen3 be downgraded to 3.4.1, and eigen 5.0.0 packaged as say eigen5?


Reproducible: Always

Steps to Reproduce:

1. Have package which needs Eigen3, with the 3.* version.

Actual Results:

CMake Error at CMakeLists.txt:377 (find_package):
  Could not find a configuration file for package "Eigen3" that is compatible
  with requested version "3.3.7".
  The following configuration files were considered but not accepted:
    /usr/share/cmake/eigen3/Eigen3Config.cmake, version: 5.0.1
      The version found is not compatible with the version requested.


Expected Results:

Package eigen3 provides Eigen in version 3.* for the foreseeable future.

Comment 1 Sandro Mani 2026-03-12 16:46:49 UTC
Probably the best would be to just call it eigen and make eigen3 a compat package.

Comment 2 Jan Pazdziora 2026-03-12 17:01:38 UTC
There used to be eigen: https://src.fedoraproject.org/rpms/eigen/commits/rawhide.

Not sure how feasible it would be revive that component name and what clashes it might cause.

Comment 3 Jan Pazdziora 2026-03-13 18:44:57 UTC
I already forgot that you actually provided a patch for prusa-slicer in src.fedoraproject.org/rpms/prusa-slicer/pull-request/60 (and I actually commented on it back then). I plan to include that fix via https://src.fedoraproject.org/rpms/prusa-slicer/pull-request/66.

I still think that having eigen3 with version 5.* is weird but the severity of the issue specifically for prusa-slicer is lower.

Comment 4 Laurent Rineau 2026-03-20 22:06:55 UTC
Note that the Eigen software is still Eigen3, version 5.0.1. https://gitlab.com/libeigen/eigen/-/releases/5.0.1

See the explanation in the release notes for the version 5.0.0: https://libeigen.gitlab.io/releases/5.0/#versioning

> This release marks a transition to Semantic Versioning. Previously, Eigen used a WORLD.MAJOR.MINOR scheme. From now on, version numbers will follow the MAJOR.MINOR.PATCH format, indicating breaking changes, new features, and bug fixes, respectively. The WORLD version will remain 3 for this and subsequent releases for posterity. See the table below:
> 
> ╔═════════╦═════╦═════╗
> ║ Release ║ 3.4 ║ 5.0 ║
> ╠═════════╬═════╬═════╣
> ║ WORLD   ║  3  ║  3  ║
> ║ MAJOR   ║  4  ║  5  ║
> ║ MINOR   ║  0  ║  0  ║
> ║ PATCH   ║  -  ║  0  ║
> ╚═════════╩═════╩═════╝

The "world" version of Eigen 5.0.1 is still 3.

As for what the other distributions are doing: https://repology.org/project/eigen/versions

A few examples:
  - Debian/Ubuntu package name is `eigen3`, and they are still not packaging anything after version 3.4.0 https://tracker.debian.org/pkg/eigen3. There was [eigen (version 1)](https://tracker.debian.org/pkg/eigen) and [`eigen2`](https://tracker.debian.org/pkg/eigen2) in the past, but they were removed long ago. I am not sure 
  - In ArchLinux and ConanCenter, the package name is `eigen`. They have upgraded to version 5.0.1, but they also have a package for version 3.4.1 (named `eigen3` in the case of ArchLinux)
  - In vcpkg, the `eigen3` package is now of version 5.0.1 (same as Fedora Rawhide)
  - in Nix, the package named `eigen` is stuck at version 3.4.0, and they also have `eigen_2`, `eigen_3_4_0`, and `eigen_5` (the later being version 5.0.1). See https://github.com/NixOS/nixpkgs/tree/nixos-unstable/pkgs/by-name/ei

So, hard to tell.

Note that in the [upstream Eigen Git repository](https://gitlab.com/libeigen/eigen/-/tree/5.0.1?ref_type=tags):
  - the package config file is named `eigen3.pc`
  - the CMake config file is name `Eigen3Config.cmake`

So the upstream developers consider that the software is still name `eigen3` or `Eigen3`, and not `eigen`/`Eigen` nor `eigen5`/`Eigen5`.

Comment 5 Sandro Mani 2026-03-21 07:24:38 UTC
Thanks for that analysis. I'd say let's keep eigen3 for now, and if the 3 starts disappearing from the .pc and cmake module names we can re-evaluate.