Les Mikesell lesmikesell@gmail.com wrote:
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.
The versionlock plugin exist for this purpose. But you are correct with the rest of your thoughts.