On Fri, May 18, 2018 at 8:27 AM Martin Jackson <mhjacks@xxxxxxxxxx> wrote: > I agree that it makes sense to associate EPIC releases with EL "point" > or "y" releases. > Some orgs (like us) download new content on timers, and while it's not > wrong to say that people should read release notes and updates, there is > currently a *lot* of content in EPEL etc to keep track of, and I think > people find it really valuable to have a repo that makes the "don't > overwrite/upgrade core" promise. I like the differentiation that is > starting to develop in the CentOS ecosystem where there are some more > "experimental" repos (like YUM4) that *do* overwrite, and say so > explicitly. The ecosystem also has good tools to mix and match these > repositories with core content (pulp/Satellite). Generally, we sync all > of EPEL but only use the command-line bits; I'm unaware of any user > reporting problems due to a GTK rebase in an EL minor release. > IUS used to talk a bit about repo safety on their web page, does this > need to be something more explicit for repos in general? Or something > that might be reflected in metadata somehow? One of the things that I've been talking to the DNF team about is making DNF/YUM4 more repo-aware so that it follows user tracks on where packages come from unless the user specifically requests it to be switched. This behavior would help resolve a long-standing issue of user expectations on following certain update paths (w.r.t. package update sources). Things like EPIC would be generally less dangerous because the risk of switching between sources mid-stream (as current Yum/DNF behavior is now) would be substantially lower. This feature has always been available to us, we just never wired it up. So we would get one of the principal benefits of Modularity for virtually all packages for free. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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/message/QIZQM2CJ7HBYFMRISQDC3ODJBQWW7NLQ/
