CentOS Stream 9 now available

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.
5 Likes

“Red Hat decided to not ship all packages that are built from RHEL spec files.”
https://wiki.centos.org/FAQ/CentOS8/UnshippedPackages

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.

I think that if you run:

dnf build-dep anaconda

It should not fail but on Stream 9 it does fail.

File a bug please? I’m sure @carlwgeorge would be happy to follow up. Us at EPEL are equally inconvenienced by this

Get someone to automate the process of locating all of the unshipped build dependencies and putting them in CRB, please?

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.

What if I file a request for a build dependency to be added to a public repo and it gets rejected?

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.