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

Fri Jan 17 20:50:34 UTC 2014
Ljubomir Ljubojevic <centos at plnet.rs>

On 01/17/2014 09:10 PM, Manuel Wolfshant wrote:
> 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.

Problem with versionlock is that it is static, manual, per-user 
solution, right? What happens if in 2 months or 2 years list of those 
packages changes? Who will change it? user? on every single system?

Less, are you speaking about repositories with equal value or with 
different values? Let me explain:

"clearos" repo has Priority=1,
"base" repo has Priority=2.
both have package named "httpd"
"yum list httpd" will only show package from "clearos" repo, package 
from "base" is hidden, discarded. Even if it has larger version. Only 
way to show it is using "--showduplicates" switch.

Ljubomir Ljubojevic
(Love is in the Air)
PL Computers
Serbia, Europe

StarOS, Mikrotik and CentOS/RHEL/Linux consultant