If I’m understanding correctly, this is about “why” we aren’t just rebasing certain packages to the latest/newest (gimp, inkscape, a recent one was about firefox in our IRC channel, and perhaps others), including some packages that third-party repos like EPEL/rpmfusion already have, or not re-enabling features that our upstream purposely disables. Perhaps this is being seen as a “missed opportunity”.
It’s not that we can’t, we don’t because we are following our upstream 1:1 and rely on Special Interest Groups within the project and third-party repositories to provide add-ons to enhance the user experience[1]. By default, we provide extra release packages (as described here and here) to try to help provide easy access to that enhanced experience, if the user chooses[2][3]. Granted, new users may not be aware of this sort of thing.
It should be noted that EPEL and RPMFusion have been around for a very, very long time serving primarily RHEL but also other rebuilds (like CentOS past and present). They have plenty of experience in this area. As a general rule, they do not replace/update base packages. Instead, they enhance the enterprise linux experience with useful add-on packages.
[1] The reason why we don’t is that it will make us no longer 1:1 with our upstream. However, we have SIG/FastTrack that is starting up that could potentially provide rebased packages or additional features that perhaps the other third-party repos do not have nor is our upstreams willing to backport or add in. What it’s going to come down to is one of the following:
- Put in a request for a package, and they can see what they can do
- Join/participate in the SIG to add on those packages (we have plenty of great RPM building mentors)
Helping can come down to just requesting (point 1) or joining a special interest group (point 2).
[2] EPEL as far as I know is the most popular add on repository for enterprise linux.
[3] As an example, if someone installs the raspberry pi image we have, it already has the necessary addon repositories installed and enabled to make it work. Rocky Linux (and upstream) was not built nor designed to run on a raspberry pi and this had to be built as an enhancement.