[CentOS-devel] freetype package missed in repo

On Thu, Aug 5, 2021 at 7:32 PM Brian Stinson <brian at 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 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?

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.