Description of problem: python3-rich fails to install with the following error nothing provides (python3.9dist(commonmark) < 0.10 with python3.9dist(commonmark) >= 0.9) needed by python3-rich-9.10.0-1.el9.noarch nothing provides (python3.9dist(typing-extensions) < 4 with python3.9dist(typing-extensions) >= 3.7.4) needed by python3-rich-9.10.0-1.el9.noarch Version-Release number of selected component (if applicable): 9.10.0
It appears I need to patch python3-rich requirements now as we got very recent python3-typing-extensions in epel9. The hard requirements needs (python3.9dist(typing-extensions) < 4 with python3.9dist(typing-extensions) >= 3.7.4)
Copied from bug 2043761: (In reply to Parag Nemade from comment #16) > I need to patch python3-rich requirements now as we got very recent > python3-typing-extensions in epel9. The hard requirements needs > (python3.9dist(typing-extensions) < 4 with python3.9dist(typing-extensions) > >= 3.7.4) Is there something blocking you from just upgrading it? It looks like your python-rich-9.10.0 package for EPEL9 has always been FTI due to unsatisfied dependencies: no python3dist(typing-extensions) at all until now, and still no python3dist(commonmark), bug 2085496. Meanwhile, the spec file for python-rich-12.4.4 from Rawhide works fine on EPEL9 except for the missing dependency python3dist(commonmark). If you’re worried about the incompatible updates policy, I don’t think it should apply if if nobody could ever install the old version.
The python-rich upstream is fast moving development, they introduce new dependencies as well. That is reason I wanted to see it be built and successfully working at some version with all its dependencies. There is nothing preventing me to update this package in EPEL9. Just look upstream release frequency https://github.com/Textualize/rich/tags I know about FTI and working on it. I just don't like to grab someone's package and build it in EPEL. So patiently waiting for dependencies to be built in EPEL9. I admit it was my mistake to build python-rich without checking its runtime dependencies availability in EPEL9.
That makes sense. I certainly understand the difficulty of aligning dependencies in EPEL since different backports can happen months or years apart, and version limitations or API breaks often prevent things from being updated.
I just got notification that python-rich-10.7.0-1.el9 update has been pushed to stable.