On Thu, Aug 5, 2021, at 17:54, Nico Kadel-Garcia wrote: > On Thu, Aug 5, 2021 at 11:08 AM Carl George <carl at redhat.com> wrote: > > > > On Thu, Aug 5, 2021 at 9:51 AM Nico Kadel-Garcia <nkadel at gmail.com> wrote: > > > > > > On Wed, Aug 4, 2021 at 9:03 PM Carl George <carl at redhat.com> wrote: > > > > > > > > On Wed, Aug 4, 2021 at 7:01 AM Josh Boyer <jwboyer at redhat.com> wrote: > > > > > > > > > I see it here > > > > > > > > > > > > https://koji.mbox.centos.org/koji/packageinfo?packageID=408 > > > > > > > > > > > > but not on the mirrors ... > > > > > > > > > > > > A retired package? > > > > > > > > > > Not retired, just a build that will never be shipped at this point. > > > > > > > > > > josh > > > > > > Since it was published at one time, and has now been deleted from the > > > public repos with extreme prejudice, in what way is this not > > > "retired"? > > > > > > I admit this is a first. I've never seen Red Hat or CentOS pull this > > > stunt. Has this *ever* been done before? > > > _______________________________________________ > > > CentOS-devel mailing list > > > CentOS-devel at centos.org > > > https://lists.centos.org/mailman/listinfo/centos-devel > > > > > > > Retired would be if the package was removed entirely. `dnf install > > freetype` still works, therefore the package is not retired. > > "dnf install freetype-2.9.1-5" does not. Neither does "dnf reinstall > freetype" for this previously deployed host. He'd have to do "dnf > downgrade freetype" or "rpm -U --oldpackage" for freetype, > freetype-devel, and any other RPM's built from the same SRPM. dnf distro-sync may be helpful here too > > > The 2.9.1-5 build is identical to the 2.9.1-4.el8_3.1 build. We > > removed the duplicate (which follows what happened in the RHEL nightly > > compose). Why is this so upsetting to you? > > 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. And whether this > particular dropped package is identical to an inconsistently numbered > release is no guarantee that next week, it won't be a testing gcc or > glibc version, tested in what is now RHEL 8 beta and discarded for no > predictable or published reason. CentOS Stream as presented on the mirrors is meant to reflect what’s going into the next minor version of RHEL, so if RHEL decides not to ship a build we need to reflect that. The builds in the buildsystem (which you already found) will stick around if you’re interested in specific versions. I think the Stream 9 workflows may help with some of the visibility here as we roll them out. > > It's also unlikely in the extreme that they're identical. Even if the > checksums of compiled software match, datestamps on the compiled > libraries would not. That's not likely to make a big deal, but it's > not "identical". I’m curious about this, what is important about matching library datestamps? > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > —Brian