On Sat, Feb 13, 2021 at 10:51 AM lejeczek via CentOS-devel centos-devel@centos.org wrote:

On 01/02/2021 21:19, Johnny Hughes wrote:

...

On 1/28/21 3:58 AM, lejeczek via CentOS-devel wrote:

...

Hi devel

Is that not something that needs looking into?

-> $ dnf search release | grep -i strea Last metadata expiration check: 0:07:24 ago on Thu 28 Jan 2021 09:46:52 GMT. centos-release-stream.x86_64 : CentOS-Stream release file centos-stream-release.noarch : CentOS Stream release files

Installing one package and not the other messes things a bit.

regards, L.

No it is as intended .. one of them resides in CentOS Linux 8 extras repo .. it will go away once CentOS Linux 8 reaches EOL. It allows you to install the release package, run an update to switch from CentOS Linux 8 to CentOS Stream 8 .. where the other package is automatically installed.

Yes, but it's bit messy. I'm past that issue but if I remember correctly - while still being on "regular" release and installing one package first and not the other, as wanting to migrate to stream, one would end up with conflicting dependencies. I cannot remember which of the two would have to be installed first. That was a few weeks ago, but obvious was that some deps chains there between the two were malfunctioning/in conflict.

I'm afraid it's deliberate and unavoidable. It's awkward if not impossible to do beta software without introducing breaking changes. Since CentOS 8 Stream is now the beta for RHEL software, and will contain software never published and never to be published in any RHEL release because some of it will be rejected, it cannot ever be reliably compatible with RHEL 8, and there will not be a point release or stable release of CentOS 8 for it to be compatible with.

I expect this to last 2, maybe 3 years, and either Red Hat to relent as they did with Red Hat 9 and RHEL point releases in roughly 2003, or one of the other RHEL rebuilds to take over the former "just a stable rebuild" role with CentOS has discarded.

Also while on this case - perhaps related but if not then I make apologies: when migrating to stream I ended up with centos-linux-repos-8-2.el8.noarch VS centos-stream-repos-8-2.el8.noarch on different boxes.

CentOS 8 has not yet been discarded as a point release. Don't expect any of this to be stable yet.

All involved boxes are Centos Streams, yet here also some deps logics are broken: systems with 'centos-linux-repos' seems to be behind, dis-synchronized with what systems with centos-stream-repos get. On those "behind" boxes I do: -> $ dnf install centos-stream-repos No match for argument: centos-stream-repo

I suspect you need to do a "dnf list extras" and revert or delete packages that are not part of the enabled repos. Overlaps and conflicts and are going to be inevitable for a while.

On Sat, Feb 13, 2021 at 11:43 AM Neal Gompa ngompa13@gmail.com wrote:

On Sat, Feb 13, 2021 at 11:22 AM Nico Kadel-Garcia nkadel@gmail.com wrote:

...

On Sat, Feb 13, 2021 at 10:51 AM lejeczek via CentOS-devel centos-devel@centos.org wrote:

...

On 01/02/2021 21:19, Johnny Hughes wrote:

...

On 1/28/21 3:58 AM, lejeczek via CentOS-devel wrote:

...

Hi devel

Is that not something that needs looking into?

-> $ dnf search release | grep -i strea Last metadata expiration check: 0:07:24 ago on Thu 28 Jan 2021 09:46:52 GMT. centos-release-stream.x86_64 : CentOS-Stream release file centos-stream-release.noarch : CentOS Stream release files

Installing one package and not the other messes things a bit.

regards, L.

No it is as intended .. one of them resides in CentOS Linux 8 extras repo .. it will go away once CentOS Linux 8 reaches EOL. It allows you to install the release package, run an update to switch from CentOS Linux 8 to CentOS Stream 8 .. where the other package is automatically installed.

Yes, but it's bit messy. I'm past that issue but if I remember correctly - while still being on "regular" release and installing one package first and not the other, as wanting to migrate to stream, one would end up with conflicting dependencies. I cannot remember which of the two would have to be installed first. That was a few weeks ago, but obvious was that some deps chains there between the two were malfunctioning/in conflict.

I'm afraid it's deliberate and unavoidable. It's awkward if not impossible to do beta software without introducing breaking changes. Since CentOS 8 Stream is now the beta for RHEL software, and will contain software never published and never to be published in any RHEL release because some of it will be rejected, it cannot ever be reliably compatible with RHEL 8, and there will not be a point release or stable release of CentOS 8 for it to be compatible with.

I expect this to last 2, maybe 3 years, and either Red Hat to relent as they did with Red Hat 9 and RHEL point releases in roughly 2003, or one of the other RHEL rebuilds to take over the former "just a stable rebuild" role with CentOS has discarded.

Please stop talking as if you know what's going on. You clearly don't.

Sadly, I remember these kinds of arguments from roughly 2003. Point releases were back in use in a year. Calling them "service packs" was, and is, merely a distinct label for the same thing, and no one calls them "service packs".

There is work going on to try to clean up these things, but it's not simple to do. It's not like everyone has a freaking Ph.D. in dependency management.

Well, no. People who did wouldn't have switched CentOS 8 to a "stream-only" release and expected it not to break things unpredictably from now until CentOS reverts to point releases. I'm noticing in the discussion that Red Hat is not stopping point releases, new media with new sets of tested and compatible. It's just that CentOS won't see them anymore, and will always be the beta for RHEL, or that is the theory.

The issue here is that CentOS repository structure is stupid, and we can't easily reuse the same repo definitions to upgrade from CentOS Linux 8 to CentOS Stream 8.

I agree that RHEL 8 repository structure is stupid. "BaseOS?" "AppStream?" "PowerTools?" "Devel?" Who cares? Trying to outguess ill-defined categorization to figure out which repo "rpmbuild" or the "quota" and "quata-devel" packages, which are in two distinct repos, is not sane.

It's not trivial, but it is scriptable with the same class of tools used to switch RHEL to Scientific Linux to WhiteBox to CentOS to Amazon Linux to any of the other RHEL based distros.. As long as the major releases involved are equivalent, and as long as RPM itself does not have breaking divergences. The key is, typically, to activate a downgrade as needed. The big problem is when packages get renamed or provide alternative packages for the same requirement, such as the "centos-release" or the adventures of packages that migrate from EPEL to RHEL, such as various python packages that switched from "python36-devel" package renamed to "python3-deve" for RHEL and CentOs 7. The dependencies got hairy with that one, and third-party repositories such as those for docker-ce or vendor published packages can be.... adventuresome.

That's why the upgrade guide[1] lists that users need to use "dnf swap" to switch repository definitions.

Sure, and that activates a set of the necessary, scriptable changes. Expect localized or third party dependencies to fracture in the process.

Also, your revisionism of Red Hat Linux history has already been thoroughly disproven[2][3] and I wish you'd stop it. CentOS Linux 8 is continuing through the end of the year, and CentOS 9 will only be available in the Stream variant.

Disagreed with by you is not disproven. For example, the claim that "there are no longer point releases, they are service packs" is nonsensical. RHEL's own release notes refer to them with "7.2", "7.3", etc. numbering. Whether or not the release notes also refer to them as service updates, the very titles of the release nots are referring to them as point releases.

Yeah I read those. I'd misremembered RHEL 2.1 as being after Red Hat 9, primarily because I wasn't playing with Alphas back then. I had the opportunity but was glad, later, I didn't invest too much of my time in the Alphas.

But even RHEL 2.1 did 7 point releases, referred to in Red Hat's listings as "updates". And even if RHEL wasn't publishing distinct repos for distinct point releases, as CentOS does, they published distinct media with the RPMs and SRPMs from those point releases. I've personally bind-mounted those ISO images and used them *precisely* as CentOS has published point releases until now, as a reference stable repository for deployments, because suckling directly from a "stream" can be very destabilizing. This was particularly true for kernel regressions, which can be *very* difficult to avoid and can take out critical serivices *hard* when an unexpected kernel and hardware incompatibility pop up. (Ask about the Victoria's Secret "1100 servers just refused to reboot!!!" problem if you're curious.)

The kernel regression instability problem has gotten better with virtual machines, containers. and their spinster aunt, chroot cages. But it still scares me for bulky environments.

Nico Kadel-Garcia