[CentOS-devel] Upgrade to Stream wants to downgrade e.g. httpd

Fri Jan 15 15:23:40 UTC 2021
Neal Gompa <ngompa13 at gmail.com>

On Thu, Jan 14, 2021 at 11:06 PM Nico Kadel-Garcia <nkadel at gmail.com> wrote:
>
> On Thu, Jan 14, 2021 at 9:12 PM Carl George <carl at redhat.com> wrote:
> >
> > I have yet to see an actual problem presented other than "I don't like
> > the appearance of a downgrade".  It's not ideal but it's also not
> > causing an actual issue.  As long as RHEL maintainers add digits after
> > the %{?dist} macro in the release field, it will be possible to end up
> > in this situation.  CentOS cannot solve this with the current
> > implementation of modularity in MBS.  The right place for this
> > feedback is upstream MBS.
>
> Then you don't build software with "mock". Modularity RPM numbering
> breaks dependencies unpredictably. In fact, Modularity breaks
> dependencies, period. It's been a strong reason not to update to RHEL
> 8 or CentOs 8,along with foolishness like hte multiple overlapping yum
> repos with the same packages and the recent decision to abandon point
> releases in favor of using the CentOS users as the beta test group for
> RHEL without advance notification. The refusal to publishing the
> "devel" packages used to compile RHEL and CentOS software was
> similarly unwelcome, though that's been addressed with the "Devel"
> channel.
>
> I do hope that RHEL elects to abandon all three practices for RHEL 9.
> and CentOS 9. In the interim, it's made it very difficult to recommend
> RHEL 8 or CentOS 8. There hasn't been anything that demands either of
> them. Gnutls for Samba was a problem, but the "compat-gnutls34 "
> packages from sergiomb seem to have addressed that for now.
>

I wish you'd elect to stop being so combative on the mailing list. The
way you continually blast this without understanding how it works does
not make you sound smart.

Here are the facts:

The reason this isn't a problem build side is that Mock takes in repos
generated by Koji to build packages. The MBS cherry-picks stuff and
generates a buildroot repository for building a module on the fly.
Koji *does not care* about NVRs other than that they're unique.
Everything else? That's *your* problem.

While it's true that modules introduce complexity to dependency
resolution, it's unfair to state that modules "break dependencies".
This is not different than what happens when you have a bunch of third
party repos, or a mixture of SCLs with some unfiltered dependencies,
and so on. And RHEL has always not included everything needed to make
RHEL.

At the end of the day, the only constant is change, and if you can't
figure out how to adapt, then I don't know how you'll be able to keep
doing your work.

-- 
真実はいつも一つ!/ Always, there's only one truth!