On Thu, May 30, 2019, at 6:57 PM, Stephen Gallagher wrote: > On Thu, May 30, 2019 at 4:25 PM James Cassell > <fedoraproject@xxxxxxxxxxxxx> wrote: > > > > > > > > > Historical composes are intended to be frozen and unchanging, but this > > > > approach leaves open the possibility of tagging other builds into > > > > epel8-8.Y and regenerating the compose if the need arises. It will > > > > need to be communicated that these repositories will not receive > > > > updates and are intended to be only a snapshot of the past that is > > > > known to work with a particular RHEL 8.Y base. > > > > > > > This will be very helpful, especially if the epel-release .repo file honors the $releasever variable. > > > Can you explain what behavior you see here? I can't really parse from > your reply what you think/expect to have happen here, and I'd like to > make sure we address it properly. The use case is preventing updates past a minor version without explicit administrator action. We're able to do this by forcing the $releasever yum variable to be 7.50 (for RHEL) or 7.5.1804 (for CentOS). It would be convenient to keep this approach working by using the yum var in the repo file, with requisite symlinks in place on the mirrors. The repo file as is today would likely work for this purpose (but I don't have it in front of me to verify.) V/r, James Cassell _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
