On Thu, Aug 5, 2021 at 7:32 PM Brian Stinson brian@bstinson.com wrote:
On Thu, Aug 5, 2021, at 17:54, Nico Kadel-Garcia wrote:
On Thu, Aug 5, 2021 at 11:08 AM Carl George carl@redhat.com wrote:
On Thu, Aug 5, 2021 at 9:51 AM Nico Kadel-Garcia nkadel@gmail.com wrote:
On Wed, Aug 4, 2021 at 9:03 PM Carl George carl@redhat.com wrote:
On Wed, Aug 4, 2021 at 7:01 AM Josh Boyer jwboyer@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@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?
Ordinarily? Nothing. But libraries are not the only files in RPMs. Also even when the source code is identical, libraries can differ due to their compilation. That's not likely to be significantly different in a mock or koji build environment, but it *can*, especially due to small changes in gcc or glibc. And there's that word, "likely". And worse, some source control systems are prone to programmers activating datestamp, author or commit references in text fields, and some programmers use those sorts of source control generated data for "version" or comment fields. This used to be very popular indeed with Subversion source control, it wasn't well supported at first with git and remains much less popular. Some programmers even generated their version.h file with every compilation: From memory, that was part of the bootstrapping procedure of compiling gcc.
I'm not saying this is likely with freetype, or likely to break things on a specific project, people are usually sensible about its use. But if the git repos have such features enabled for specific configuration files, well, checksum consistency of compiled software is unlikely. with that software, especially if it gets embedded in a "version.h" file.