[CentOS-devel] Repository structures for SIG and variants in the future

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.  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?

-- 
   Les Mikesell
     lesmikesell at gmail.com