Les Mikesell <lesmikesell at gmail.com> wrote: >On Fri, Jan 17, 2014 at 11:06 AM, Jim Perrin <jperrin at 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.