On Sun, Aug 8, 2021 at 7:45 PM Carl George <carl at redhat.com> wrote: > > On Sat, Aug 7, 2021 at 6:32 AM Nico Kadel-Garcia <nkadel at gmail.com> wrote: > > > > On Fri, Aug 6, 2021 at 9:30 AM Troy Dawson <tdawson at redhat.com> wrote: > > > > > > On Thu, Aug 5, 2021 at 3:54 PM Nico Kadel-Garcia <nkadel at gmail.com> wrote: > > >> > > >> Because this kind of unwelcome stunt is brand new as best I can tell, > > >> never pulled in 25 years as far as I can find. > > > > > > I understand the feeling, but let's take a deep breath. > > > > > > RHEL hasn't been around for 25 years, so you know you are exaggerating. > > > > I did not say "RHEL". I said Red Hat. I date back to at least Red Hat > > 4.0, in 1996, so that's not exaggeration. That's precision. OK, 4.0 > > was published in October, so 24 years and 10 months. I *think* I > > worked with a Red Hat 3.0.3, which was published in May, 1996, but I > > can't swear when that box got to my hands. > > > > > And yes, it has happened before, at least for Scientific Linux. > > > > I did not list Scientific Linux. They are not the reference > > distribution for Red Hat based distributions. Red Hat Linux was, and > > now RHEL is. I've worked extensively with Scientific Linux and am > > still active on the primary mailing list, which has quieted down a > > great deal since CERN decided not to try to publish a Scientific Linux > > 8. > > > > I'm not aware of any such instances for Scientific Linux since I first > > looked at it with Scientific Linux 5. > > > > > I definitely remember RHEL pushing some srpm's to their ftp area (back when they released srpm's), and then removing those srpm's. > > > > Name them, please, because I don't remember that *ever* happening in > > any Red Hat published operating system, whether Red Hat Linux or RHEL. > > It happens quite casually in EPEL, which has turned out to be a big > > problem for people who expect to be able to build a system from > > scratch on Thursday that matches what they built on Tuesday. > > > > > We (Scientific Linux) automatically pulled down those srpm's, built them, and pushed them out. > > > We (Scientific Linux) were contacted once by Red Hat, another time by our own users, letting us know that we'd released a package not in RHEL, and we removed it from our repos. > > > What happened? > > > Real people, and a real world happened. > > > Something happened in RHEL's workflow that was allowing srpms to be pushed. This workflow was eventually fixed. > > > We (Scientific Linux) were not properly testing our packages before pushing them out. This workflow was eventually fixed. > > > > I'm considerably less alarmed by Scientific Linux withdrawing an > > accidentally published package. Moreover that doesn't sound like a > > matching case, that sounds like a licensing issue where the package > > had to be altogether withdrawn. What package was that? An Oracle JDK > > package? > > > > I'm alarmed about a number of factors of CentOS 8 Stream. I previously > > expressed concern that CentOS 8 Stream, as a beta platform for RHEL, > > will have packages published which never make it to RHEL, which is > > confusing enough. But having them withdrawn from CentOS, because "it's > > the same as the lower numbered build published for RHEL"? That means > > updates are happening *without* making it into CentOS 8 Stream first, > > and that there is no plan to match updates that were, in fact, > > published and field tested in CentOS 8 Stream. > > > > If Red Hat is not going to integrate the successful results of beta > > testing, why are they bothering with CentOS 8 Stream? And why bother > > to *delete* the package, and break existing depolyments. > > > > The simplest working solution for this case would have been to accept > > the higher numbered "beta-tested" build as canonical, and to update > > RHEL to match the CentOS tested update, not to discard the higher > > numbered build. This would have acknowledged the role of CentOS 8 > > Stream as a beta test environment for RHEL 8, and in this case as a > > *successful* beta test environment, rather than an orphaned one as > > occurred with this particular software package. > > > > We also need to be careful about language. I've been very careful > > about mine, referring to the particular build of freetype-devel as > > "retired", and had someone try to say "retired" meant the software was > > withdrawn. No, I spoke pretty specifically of the build, I don't see > > how that seemed confusing. And it just happened above where you > > accused me of exxageration, not realizing I had said and referred to > > "Red Hat", not merely "RHEL". That one.... I won't take the blame for > > that confusion: Red Hat's decision years ago to switch the names of > > their published operating systems as "RHEL" and to revise their > > numbering scheme was roughly as much fun as the SunOS and Solaris > > naming confusion. When I say I learned a lesson with "Red Hat 4.2 when > > it came out", folks underestimate my experience by a decade. We just > > saw that happen. > > > > > Again, deep breath. > > > Please remember this (CentOS Stream) is a new workflow. > > > There are real people, and a real world, behind it. > > > There will be hickups and problems in that workflow. > > > We (Red Hat) need feedback, so we know about those problems. We appreciate that. > > > Once we (Red Hat) know, and understand the scope of the problem, it's time to figure out how to solve that problem. > > > We (Red Hat) also appreciate input on how to solve the problem. > > > > Your note is very thoughtful. In this case, I urge Red Hat *not* to > > casually delete RPMs from CentOS 8 Streams. Where possible, they > > should be either accepted as a successfully tested package for RHEL, > > or if the package failed, to revise and publish the fixed package in > > the CentOS 8 Stream. I urge you to avoid what I think is a confusing > > and difficult to validate belief, that a package with a different RPM > > release number can be considered identical to another RPM, even if the > > source code at compilation and the contents of all compiled libraries > > are identical. We, as users of RPMs, can't verify that without a great > > deal of extra work, especially when the relevant RPM and SRPM have > > been expunged from the public repositories from which they were > > previously deleted. > > You can verify it in much less time than you've spent writing > antagonistic emails on this thread. > > https://git.centos.org/rpms/freetype/c/19e0ad98e6e7570372b3601ecf949b023c603149?branch=c8s > > It's also intellectually dishonest to use the word expunged to > describe this. Expunged means to remove completely. The duplicate > build and it's artifacts are still available in our build system. > > https://koji.mbox.centos.org/koji/buildinfo?buildID=14760 In this case, that's not the public repo by which the package was originally distributed nor is it directly enabled on any CentOS system. And if you'll check, I've been really consistent about saying "expunged from the public repos". Is that admittedly public resource a repo? Without associated repodata or yum access to it, I would not call it one, especially because the word "repo" has a pretty specific meaning for RPM based operating systems. I've been accused of things a few times in this thread, several times now by someone confused by what I thought was clear language. Can we agree that this is such an occasion? I thought "expunged from the public repos" was intelligible, and mild by comparison to, "yoinked for no apparent reason from every public yum repo", which is more precise but a bit ruder. Hopefully after these threads it's clear that such deletions cause confusion and break working configuration management tools.