Re: [EPEL-devel] Mock/Copr default epel-8-* configuration to be changed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 25, 2021 at 6:19 AM Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote:
>
> On Thu, Nov 25, 2021 at 3:05 AM Miroslav Suchý <msuchy@xxxxxxxxxx> wrote:
> >
> > 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 about the
> > > situation and so I don't want to be the lightning rod :-).  But I believe
> > > that we can come to acceptable Copr/Mock solution and this needs to be
> > > 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 CentOS 8
> > > 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.
> >
> > https://docs.google.com/document/d/1wF7-7_y6Ac_oB-kCFdE6VBWPW8o8zjXd2Z0SGy4VxUA/edit?usp=sharing
> >
> > Miroslav
>
> That seems to be a succinct listing. I think you left out my
> suggestion.of "support people re-inventing point releases for CentOS",
> 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.

> The difficulty with switching mock to AlmaLinux or Rocky is that there
> is likely to be significant phase lag with new point releases by Red
> Hat, and that it will inflict quite a bandwidth burden for all the
> "mock" setups in the field. Can they scale up to handle that?

Insofar as "phase lag with new point releases", AlmaLinux made their
release 48 hours after Red Hat did with RHEL. So, frankly, I'm not
worried there with AlmaLinux.

For bandwidth burdens, mirror networks are designed to alleviate that
burden and both have those in place.




--
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux