Unfortunately, this is not a simple matter.  The 2021.1.1 release introduced backwards incompatible changes, notably the complete removal of commonly used interfaces.  See https://www.intel.com/content/www/us/en/developer/articles/technical/tbb-revamp.html for details.  Simply updating to the latest tbb release would break many Fedora packages.

On the other hand, some Fedora packages could move to the latest release were it available.  I've got a COPR repo at https://copr.fedorainfracloud.org/coprs/jjames/TBB2021/ that can be used to check compatibility.  We could introduce a tbb 2020 compatibility package, and then move the main package forward to 2021.5.0.  The danger then is that some application might end up with both the old and the new versions of the library due to some dependencies moving forward and others not.  I have tried to map out the space of Fedora tbb-using packages.  I believe these are the blocks of packages that need to move forward simultaneously to avoid trouble:

- fawkes, gazebo
- opencascade
- pmemkv
- root
- 4ti2, blender, bowtie2, coin-or-Cbc, coin-or-Cgl, coin-or-Clp, coin-or-CoinUtils, coin-or-Osi, dyninst, embree, gap-pkg-hapcryst, gap-pkg-happrime, gap-pkg-polymaking, gap-pkg-singular, gegl04, giac, gimp, glpk, gnome-photos, gutenprint, latte-integrale, luxcorerender, Macaulay2, mathicgb, oidn, opencv, OpenImageIO, opensubdiv, openvdb, polymake, prusa-slicer, pynac, python-cvxopt, python-jupymake, python-jupyter-kernel-singular, python-jupyter-polymake, python-pysingular, qepcad-B, sagemath, Singular, suitesparse, systemtap, xsane-gimp

That last group is, of course, the main issue.  The dependencies are so intertwined that none of them can move to the new version of tbb until all of them can.  That means that we can have at most 5 packages move to the new version right away: fawkes, gazebo, opencascade, pmemkv, and root.  That hardly seems worth the effort.

What we need to do is start going through all of these packages to find which are able to upgrade and which are not, then start filing upstream bugs on those that are not.  Some of the upstreams have not been active for quite awhile, so we may find ourselves needing to the the ports ourselves, which does not appear to be a trivial task.

At one point, I intended to do all this work myself.  But see my recent email to fedora-devel-list about retiring from the mathematical packages I have been tending.  I am trying to move away from the packages I maintain that use tbb, which is a demotivator to put a lot of work into tbb.  Volunteers are welcome.

I think I'd like to explore moving forward with a tbb-compat package based on 2020.3 but I don't have a timeframe yet for when I might undertake that work.

This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

For anyone interested, I have updated my COPR of tbb for version 2021.7.0: https://copr.fedorainfracloud.org/coprs/jjames/TBB2021/

I think at this point we don't have a choice, we need a parallel installable compat package. I don't have a lot of time and I'm not familiar with the building of TBB, but I can carve out some cycles to help work on this.

*** Bug 2156800 has been marked as a duplicate of this bug. ***

(In reply to Richard Shaw from comment #6)
> I think at this point we don't have a choice, we need a parallel installable
> compat package. I don't have a lot of time and I'm not familiar with the
> building of TBB, but I can carve out some cycles to help work on this.

I agree. I have recently been looking into doing this. My current thinking is to continue to publish the 2020.3 version as a tbb2020.3 package, and move the tbb package to track upstream.

The complication is that it does not appear that I can do this in a way that would allow parallel installation of both packages.

(In reply to Thomas Rodgers from comment #8)
> (In reply to Richard Shaw from comment #6)
> > I think at this point we don't have a choice, we need a parallel installable
> > compat package. I don't have a lot of time and I'm not familiar with the
> > building of TBB, but I can carve out some cycles to help work on this.
> 
> I agree. I have recently been looking into doing this. My current thinking
> is to continue to publish the 2020.3 version as a tbb2020.3 package, and
> move the tbb package to track upstream.
> 
> The complication is that it does not appear that I can do this in a way that
> would allow parallel installation of both packages.

In terms of 'when' this could land in a Fedora release, the deadline for system-wide chnage proposals
for Fedora 38 has passed. This would need to target f39.

If we can come up with a parallel installable package, I don't think this requires any sort of "system wide change" proposal/approval. It should "just work".

(In reply to Richard Shaw from comment #10)
> If we can come up with a parallel installable package, I don't think this
> requires any sort of "system wide change" proposal/approval. It should "just
> work".

The deadline for self-contained changes is Jan 17, so that doesn't leave a lot of time to get the change proposal in and approved by fesco. I already have
an approved system-wide change (boost 1.81) targeting f38 which has to take priority, so I don't practically see how I can get this done for f38.

I don't see how you can possibly make a compat package if tbb hasn't bumped the soname of the library.  Can you get upstream to bump the soname if they really have changed the ABI?

(In reply to Orion Poplawski from comment #12)
> I don't see how you can possibly make a compat package if tbb hasn't bumped
> the soname of the library.  Can you get upstream to bump the soname if they
> really have changed the ABI?

They bumped the soname of tbb .so, just not the tbbmalloc.so...so "worst of all possible choices", though logical, the ABI of tbbmalloc hasn't changed.

(In reply to Thomas Rodgers from comment #13)
> (In reply to Orion Poplawski from comment #12)
> > I don't see how you can possibly make a compat package if tbb hasn't bumped
> > the soname of the library.  Can you get upstream to bump the soname if they
> > really have changed the ABI?
> 
> They bumped the soname of tbb .so, just not the tbbmalloc.so...so "worst of
> all possible choices", though logical, the ABI of tbbmalloc hasn't changed.

So to answer the original question, sure, I can ask. I work with the TBB team on other things. I prefer that this all be parallel-installable. Gettting from here...to...there... will take work, also time, I'm going to target, tentatively, f39.

Can we split libtbbmalloc.so into a separate package, and make tbb-compat depend on it?

So libtbbmalloc.so would come from the newer TBB package, and both tbb and tbb-compat would depend on it.

(In reply to Jonathan Wakely from comment #15)
> Can we split libtbbmalloc.so into a separate package, and make tbb-compat
> depend on it?

I mean subpackage, of course. It would come from the same SRPM as the 'tbb' RPM.

Strictly speaking we don't even need a subpackage, because 'tbb-compat' could just depend on 'tbb' and get libtbbmalloc.so and libtbbmalloc_proxy.so that way.

It might be slightly cleaner to split 'tbb' into 'tbb' and 'tbb-libtbbmalloc' (or another name) but it's not actually necessary to make it work.

I've put my stab at a compat package here: https://copr.fedorainfracloud.org/coprs/orion/tbb-compat/   Tests appear to be hanging on ppc64le for some unknown reason.

Strategy is to just build libtbb and depend on the rest from the tbb package as Jonathan Wakely suggests.  Probably should also drop the python package from it as well because it conflicts and doesn't really

I've dropped the python package and the ppc64le hang seems to be intermittent - haven't seen it again.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

(In reply to Thomas Rodgers from comment #2)
> I think I'd like to explore moving forward with a tbb-compat package based
> on 2020.3 but I don't have a timeframe yet for when I might undertake that
> work.

(In reply to Orion Poplawski from comment #18)
> I've put my stab at a compat package here: https://copr.fedorainfracloud.org/coprs/orion/tbb-compat/   Tests appear to be hanging on ppc64le for some unknown reason.

> Strategy is to just build libtbb and depend on the rest from the tbb package as Jonathan Wakely suggests.  
> Probably should also drop the python package from it as well because it conflicts and doesn't really

I am about to mark this Fedora change proposal "ready for wrangler" -

https://fedoraproject.org/wiki/Changes/F39ModernizeTBB