On Fri, Jan 17, 2014 at 11:06 AM, Jim Perrin jperrin@centos.org wrote:
But, as I said, for now I will be happy with "Priorities=" and "Enabled=" for every repo's config. It will make many things easier, like creating script to change those numbers per users request (you do not have to host it). Adding them to every new config (after centos-release is updated) is not desired.
Enabled, we can likely accommodate, and I'll discuss this with the others. Priorities, I'm not sold on.
I'm not convinced any existing tools can get all of the scenarios right. Priorities might work if you want a mostly-vanilla system with one or two exceptions from 3rd parties, but probably not in the context of a variant SIG plus an assortment of exceptions. There are reasons that the conflicting (or worse, incompatible) packages exist. Sometimes you'll want some of them but there won't be a general rule about which ones and there may be new relationships to enforce. For example, a clearos package is likely to require a stock package and add configuration/management tools. Then, in the (rare, but it happens) event that a stock package update changes configuration options in an incompatible way, you'll want to hold that update back until the matching changes have been added to the clearos additional package. Whenever I've posed questions about holding updates to specific revisions, the answer has always been to 'mirror the repository' in the state you want. That never seemed desirable even in the context of locally tested states, and it seems even less desirable for a proliferation of SIG repos that need known/tested states of the base layer that is managed independently.
SCLs look moderately safe, but aren't they sort of self-contained? What if you really want the alternative program or shared library to be the preferred choice?