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

Manuel Wolfshant

wolfy at nobugconsulting.ro
Fri Jan 17 20:10:26 UTC 2014



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.




More information about the CentOS-devel mailing list