On Fri, May 18, 2018 at 8:27 AM Martin Jackson <mhjacks(a)swbell.net> 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!