In case anyone missed the news, CentOS Stream 9 is now available. This release is derived from Fedora 34 and will be the basis for RHEL 9.
There are two things I’m especially excited about with this release.
It is now possible to contribute directly to the CentOS Stream dist-git via merge (pull) request. This is a huge improvement over the contribution workflow in CentOS Stream 8.
EPEL9 is also already available so Fedora packagers can start providing additional packages to use with CentOS Stream 9 right away.
I don’t think there’s another distro maintainer that hides packages needed to build (compile) other packages. It’s practically tivoization to comply with GPL2 by giving source code but not the tools needed to compile that source code…
To be fair, the situation is much better now and missing -devel packages can be requested for inclusion into Powertools (Stream 8) / CRB (Stream 9).
The original decision was unfortunate but IMHO (as an external observer) the rationale could be simply to lower RH’s support obligations. Given the specs are available people can rebuild it, and the EPEL project used to do that though it’s a hassle.
It would not be reasonable to do that. Such requests would be rejected automatically, since RHEL maintainers want specific reasons for such packages to be shipped.
And indeed, it makes sense for them to do that, because packages in Red Hat Enterprise Linux 9 have to be maintained for a very long time, and packages that external consumers cannot build against are not bound to the same restrictions in terms of API/ABI stability.
As it is, I’ve had great success requesting packages to be shipped that I need when I give them a reason for it and tie it to something that would be useful for people to have. I’ve done a fair bit of this for getting KDE Plasma ready in EPEL 9, for example.
But we’re not going to do mass requests for development packages, because that might lead to them just saying “no” to every request, even the reasonable ones.
All packages built by the spec files are available in koji (c8s instance, c9s instance), they’re just not included in the compose unless they are intended to be included in RHEL. Including a package in RHEL has support implications. If there is a package you’d like to see shipped in RHEL, follow the process in the wiki link you cited.
Surely rather than engaging in hypotheticals you should just try filing such a bug? If you have a valid use case it will likely not get rejected. If your use case is “I just want to see if you will add it” then… it will likely get rejected.
it may be the request needs improvement. If you have an example of one that has been rejected, then we can work on it as a group to reinforce the driving requirements.
It would be great if the ISOs were to be made available via BitTorrent, as there’s a funny feeling when having to download ISOs directly via HTTP (not HTTPS) from Index of /9-stream/BaseOS/x86_64/iso
I know that on Download there’s a " ISOs are also available via Torrent." part, but that links point to Stream 8 mirrors who don’t actually have any .torrent files for download. Anyway, without TLS transport, there’s no guarantee that any ISO or .torrent file are the real ones.