On Mon, Nov 29, 2021 at 6:42 AM Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > > On Sun, 28 Nov 2021 at 19:32, Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote: > > > > On Sun, Nov 28, 2021 at 7:06 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > > > > On Thu, Nov 25, 2021 at 2:02 PM Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote: > > > > > > > > On Thu, Nov 25, 2021 at 8:26 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > > > > > > > > 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. > > > > > > > > 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. > > > > You're correct. With the current setup, it's also relatively simple to > > revert to the "frozen" release, which handles most of the regression > > situations. And Fedora releases are nowhere near so long-lived as RHEL > > and EPEL, so it tends to be less of a long-lived problem. > > > > > RHEL *does* maintain multiple old versions, but their system is > > > completely different and supports that capability. > > > > What would it take to get Fedora, or at least EPEL, to preserve old > > releases in the default published repos? I appreciate that it would > > require thought and expand them noticeably, especially for bulky and > > frequently updating components like chromium. I admit to not having > > numbers on how much churn happens there: does anyone have numbers? > > In order to keep older package releases, it would require changes to > the compose tool pungi. It would also have to make it so it worked for > EPEL versus Fedora. [Fedora Linux releases have grown to the point > that many mirrors can barely carry the OS as is.. adding in older > packages is out of the question for them.] I do not have numbers on > how often packages churn or which ones churn the most. > EPEL is big enough that I begged Troy Dawson to untag duplicate copies of KDE Plasma so that I could have enough free space for a second mirror job to work. Between EPEL and EPEL Next for 8, it's pretty huge. I would say with all the EPEL repositories, it matches the size of Fedora Linux release trees. I don't think anyone would be too happy with more. And keep in mind that EPEL trees last for 10 years on the mirror network before being frozen. That's a lot of updates over the years. If Fedora and EPEL were to have older versions, we'd have to have a dedicated CDN endpoint for them, because mirrors would seriously have trouble taking it. -- 真実はいつも一つ！/ 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
