On Thu, Nov 25, 2021 at 2:02 PM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
On Thu, Nov 25, 2021 at 8:26 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
> On Thu, Nov 25, 2021 at 6:19 AM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
> > On Thu, Nov 25, 2021 at 3:05 AM Miroslav Suchý <msuchy(a)redhat.com>
> > >
> > > Dne 22. 11. 21 v 15:00 Pavel Raiskup napsal(a):
> > > > Hello Fedora EPEL maintainers!
> > > >
> > > > First I don't feel comfortable announcing this, I'm not happy
> > > > situation and so I don't want to be the lightning rod :-). But I
> > > > that we can come to acceptable Copr/Mock solution and this needs to
> > > > discussed... so here we are.
> > > >
> > > > By the end of the year 2021 we have to fix our default EPEL 8 Mock
> > > > configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) as
> > > > goes EOL by then.
> > >
> > >
> > > I wrote down the possible options and their pros and cons and I done my
best to catch all the feedback here.
> > >
> > >
> > >
> > > Miroslav
> > That seems to be a succinct listing. I think you left out my
> > suggestion.of "support people re-inventing point releases for
> > which is what major CentOS users will do using internal mirrors. due
> > to concern about unexpected and unwelcome updates of CentOS Stream,
> > while they assess whether AlmaLinux or Rocky are reliable and stable
> > enough to use. It's not an uncommon behavior for EPEL itself, partly
> > because of EPEL's bad habit of deleting RPMs without warning and
> > stripping out all previous releases. That's caused me problems with
> > chromium and firefox when updates were incompatible with contemporary
> > regression testing systems.
> It's not a "bad habit", it happens because when packages are retired,
> keeping the packages there does a disservice to the community by
> effectively forcing a maintenance burden when there's no maintainer.
> As for stripping out previous releases, that's just how Pungi and
> Bodhi do update composes at the moment. Someday that'll be fixed, but
> then we'd have to come up with a policy on how many because there are
> storage concerns for mirrors if we kept everything published forever.
It causes problems and confusion for people who need to lock down
evisting versions for deployment. And it happens for packages that are
not retired, but merely updated. I was bitten by it myself with
chromium updates last year. It forces users of EPEL to maintain
internal repos, or out of band access to previously accessible RPMs.
It's destabilizing and breaks the use of bills-of-material based
deployments with complete lists of all desired RPMs.
Storage and bandwidth concerns are legitimate concerns, as is
potentially continuing to publish older releases with known
vulnerabilities or bugs. But neither Fedora nor RHEL simply discard
previously published versions this way, they aggregate new releases. I
consider this a longstanding bug for EPEL, and one of the reasons I
set up internal mirrors in large deployments.
This is not true. Fedora and EPEL share the same system, and have the
same issues. The only difference is that the release repo is frozen in
Fedora, so only the updates repo is affected this way. So there's at
most two versions of a package at any time.
RHEL *does* maintain multiple old versions, but their system is
completely different and supports that capability.
真実はいつも一つ！/ Always, there's only one truth!