Furthering the evolution of CentOS Stream - "CentOS Stream will now be the sole repository for public RHEL-related source code releases."
redhat.com/en/blog/furthering-evolution-cento...Posted Jun 21, 2023, 12:12 PM UTC
2928
redhat.com
Can someone explain for a newcomer what this all means? Seen this cross-posted a bunch of places this morning and it seems significant but I have no clue.
2
CentOS Stream is now upstream for next RHEL release. If you have RHEL 9.2 then in CentOS Stream 9 repository there are changes that will land in RHEL 9.3. So for example if in RHEL 9.2 there is library called libfoo 1.0 and in version 9.3 it will be libfoo 2.0 then it will land in CentOS Stream 9. However if Red Hate update this library in 9.2 to libfoo 1.5 then there won't be source code for that change as CentOS Stream doesn't track 9.2.
This means creating RHEL compatible distributions (like Rocky Linux or Alma Linux) will be much harder as they won't have access to the source of RHEL releases anymore.
2
if in RHEL 9.2 there is library called libfoo 1.0 and in version 9.3 it will be libfoo 2.0
Assumind that libfoo is using semantic versions, then that will virtually never happen. Version 2.0 (in semver terms) is an indication that the interface has some change that isn't backward compatible -- it's a breaking change. And not shipping changes of that type is one of the primary qualities of RHEL.
However if Red Hate update this library in 9.2 to libfoo 1.5
That also won't happen. RHEL's model is that version rebases, such as libfoo 1.0 -> 1.5 only happen when systems upgrade from one minor release to another. Because each supported minor release is (effectively or really) a git branch, that means that version rebases only happen in the "main" branch for the major release, which is the branch used to create CentOS Stream. Those rebases are not merged to the branches that already exist for available minor releases, they'll only be present in future git branches that are created to support future minor releases.
1
That was very simplified example to show how Red Hat can make changes downstream without CentOS Stream.
1
However if Red Hat update this library in 9.2 to libfoo 1.5
That also won't happen.
The details of the package name and version number don't really matter. Let's substitute that with "if Red Hat update 9.2 with a new release incorporating bug fixes and/or security fixes"; it seems that this new release will not appear at https://gitlab.com/redhat/centos-stream/rpms, because the c9s branch for libfoo is now being used to package version 2.0 ahead of RHEL 9.3's release.
1
because the c9s branch for libfoo is now being used to package version 2.0 ahead of RHEL 9.3's release
I mean... they do matter. Red Hat will not "package version 2.0" in any branch of RHEL (including Stream) if that major release started with version 1.0 or 1.5.
But yes, if they rebase from version 1.0 to 1.5 in c9s, and there's a bug or security fix published to a minor release for version 1.0 after that point, the fix for 1.0 won't appear in c9s.
1
Most packages can be reproduced from Stream, but rebuilds will need some external input to indicate which commit in the git repo needs to be built. In the old centos git repos, rebuilds just needed to rebuild whatever was at the tip.
But there are a few package types that won't appear in the Stream git repos. Especially, any update (security or critical bug fix) to any package which already been rebased to a new stable upstream release in Stream probably won't be reproducible directly from Stream git.
It's a small set of packages, and orgs that are dedicated to providing a stable release will surely be able to continue to do so. But it'll be harder for them to argue that their value is in providing a 100% direct rebuild of RHEL, and explaining why their product is viable will also probably make it much harder for them to argue that Stream isn't viable (which at least one of them has been pretty vocally doing.)
That is, if you're building a GNU/Linux distribution, and the story you have to tell is "We're publishing CentOS Stream packages, but old versions in some cases," the thing you have to offer looks a little silly. And that's basically what rebuilds have been offering the whole time.
1
Can't see how this ends well for Alma and Rocky.
I guess they'll have to either (a) purchase one RHEL subscription, or else (b) get the SRPMs from somebody else who has a RHEL subscription. One of those free RHEL developer subscriptions would suffice.
They'll be perfectly fine.
The real impact is this temporarily makes it significantly more annoying for the general public to view the released code, at least until somebody else starts rehosting the SPRMs. Presumably somebody will start doing this sooner or later.
a and b would def be against the RHEL TOS and if not they are certainly going to put those in.
I don't think it's against the TOS to redistribute sources, only built packages.
Sources they are required by the license (GPL) to allow redistribution. However they can restrict the redistribution of trademarks and include those in the source package. Which effectively forbids redistribution without a bunch of work to strip out the trademarks.
Red Hat likes to walk a fine line with making sources available (as required) while finding ways to make using them difficult.
Right.
Most of the packaging is GPL-licensed anyway (it's the default license for Fedora specs unless another license is explicitly specified) so you cannot add extra use restrictions on top of that without permission from all copyright holders, which would be impractical.Edit: I'm wrong
I can't see how it makes much difference. Couldn't you just keep track of the NEVRA of the packages shipped in RHEL, and match them to the CentOS Stream package versions. Then just build those packages. Or not even build them, but re-use the actual packages, and only build the ones which need to have trademarks stripped and so forth.
Not all NEVRAS in RHEL are in Stream, is the problem
Those that aren't in Stream aren't in Alma/Rocky either. (edit: Wrong, there's of course the 6 months after release).
Unfortunately incorrect. RHEL forks Stream to release it, and patches are not upstreamed 1:1 into Stream, in all cases. The kernel is a good example of this.
Edit to add and clarify:
This is not a 'widespread' problem. Most of the packages are developed directly in Stream, but have different ordering of the patches in some cases, and also do not give us an indication of what RHEL release they may (or may not) belong to.
No, IIUC (I work for Red Hat but not on how sources are distributed) CentOS Stream RPM sources are developed and distributed in GitLab and they can recreate RHEL using Stream sources.
Alma/Rocky are basically frozen releases of CentOS stream.No they're not. RHEL minor releases branch from CentOS Stream a few months before release. Then there are six months until the next minor release. So that's 9 months of change history missing from CentOS Stream. Think of CentOS Stream as being like the "master/main branch" for a particular major version of RHEL. Nobody cuts stable releases directly from master.
For practical example: any packages ending in .el8 or .el9 are probably (but not necessarily) the same; any packages ending in e.g. .el8_8 or .el9_2 were updated after branching from CentOS Stream and will be different (at minimum, the revision number is different).
This is incorrect, RHEL minor releases branch very close to release. I just checked the RHEL 9.2 kernel and the internal branch for .el9_2 packages stayed in sync with stream until 2 weeks after 9.2 was released.
For the remaining six months, most packages are fine (I would guess 95-99%); either they do not get any update, or they only get bugfixes, or they are never rebased so the patches are available in Stream.
The kernel is different from userspace. I don't know how that works. It's special.
I work for Red Hat too and can only discuss the publicly-visible things on reddit. You can compare the publicly-available c9s/c8s changelogs to the 9.2/8.8 changelogs from Rocky or Alma and see when they diverge. I would pick some package that changes frequently in c9s/c8s, and is not the kernel, and does not have that underscore near the end of the revision number indicating changes made for a particular minor release outside CentOS Stream.
Come on rocky, you can do it