On Fri, Mar 3, 2023 at 11:57 AM Nick Howitt via epel-devel <epel-devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > On 03/03/2023 15:33, Daniel P. Berrangé wrote: > > On Fri, Mar 03, 2023 at 06:55:46AM -0800, Troy Dawson wrote: > > We are currently in the middle of changing the workflow of retiring these > packages. We are changing it so that the package maintainer doesn't do the > removing. It will be automated, or semi-automated, so there is a > consistent time when all of them are removed. > > That's a good idea. > > When do you actually remove the packages from the EPEL repository? > It has been agreed that it will be after both Alma and Rocky have their > latest release out. > > Ok, that's good, and should at least avoid breaking my upstream CI > use case since our containers should transparently start receiving > the 9.2 content when Alma releases their rebuilt container iamges. > > But how long after? > Immediately after? a month? 6 months? > > I personally am leaning towards a month after. > Here is my reasoning. > At the time a new RHEL release is released, we take a snapshot of the EPEL > repo and put it in the archives. > So all the packages that were built, and run on RHEL 9.1 are available in > that archive. > > snip > > Anyway, if some users are still doing new installs of RHEL 9.1 (or > compatible) after that month, then they should probably add the epel 9.1 > archive to their yum repositories. > > That's interesting, I didn't know about the y-stream archive > snapshots. > > Is there any mileage in considering a way to make the use of the epel > 9.1 archive automatic so users don't have risk of breakage needing manual > reconfiguration to keep working ? > > eg perhaps have 2 yum repos provided and enabled by epel-release. One > repo URL always the latest release and one repo URL always the current > 9.x release number, with a lower priority number set. The latter repo > initially empty of packages, but at the start of 9.2 it receives the > snapshot of 9.1 content, and so becomes dominent over the former repo > which will henceforth be holding 9.2 content. > > With regards, > Daniel > > Is this one of those cases where it would be better not to use an el9 package suffix but something alphanumerically lower than el9, then Redhat's packages would always take priority if they come along? Changing the disttag to sort lower will only have an effect if the RHEL package has the exact same version and release digit as the EPEL package. This almost never happens in practice. The RHEL maintainer is much more likely to select an older version for specific reasons or choose the same version with a higher release to provide a clean upgrade path. > > Nick > _______________________________________________ > epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to epel-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/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Carl George _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-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/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
