[CentOS-devel] centos-release-stream.x86_64 VS centos-stream-release.noarch

On Sat, Feb 13, 2021 at 11:43 AM Neal Gompa <ngompa13 at gmail.com> wrote:
>
> On Sat, Feb 13, 2021 at 11:22 AM Nico Kadel-Garcia <nkadel at gmail.com> wrote:
> >
> > On Sat, Feb 13, 2021 at 10:51 AM lejeczek via CentOS-devel
> > <centos-devel at 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.

> [1]: https://www.centos.org/centos-stream/#converting-from-centos-linux-to-centos-stream
> [2]: https://lists.centos.org/pipermail/centos-devel/2021-February/076419.html
> [3]: https://lists.centos.org/pipermail/centos-devel/2021-February/076425.html

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