[CentOS-devel] Packaging Office hours at 16:00 UTC today

Wed Jan 22 22:45:14 UTC 2014
Ljubomir Ljubojevic <centos at plnet.rs>

On 01/22/2014 09:53 PM, Les Mikesell wrote:
> On Wed, Jan 22, 2014 at 2:33 PM, Ljubomir Ljubojevic <centos at plnet.rs> wrote:
>> If CentOS has any desire to expand on the market share, it should stop
>> being "only-for-admins" distro.
> No, the base distribution has to remain a toolbox with all the
> options.  It should be the role of the SIGs to build respins already
> configured for common uses.   But, consider the problem it introduces
> if you expect the respins to pull updates directly from the base.  A
> distro like ClearOS is going to have configuration/management packages
> that operate on top of the stock packages.  That means that every time
> one of the managed stock packages is updated there is a chance (rare,
> but it happens) that its config options will change in a way that will
> break things and it should be held back until the corresponding change
> is made in the wrapper packages.   That's not a problem if every SIG
> mirrors all of the base updates so they can manage the timing, but
> that seems horribly inefficient.

If you do not have priorities in place, all hell can break loose. If you 
have priorities in place, then rebuild of important package can trigger 
an alarm for SiG that relies on that package, and as a prevention 
measure that SiG can place older package in their own repository (that 
has higher priority) until they can assess the situation. Main CentOS 
devs would also be alerted and would, if this was agreed upon, wait with 
release of update, or maybe CentOS devs would move older package in 
SiG's repo, or some sort of automatic move of older package would be 

Anyway, old package would be lifted to higher repo and only then newer 
package would be pushed to the Core reposiitory. That way regular CentOS 
users would get updated package, but users of that SiG's Variant would 
be able to keep older version.

As soon as SiG sees there is no problem, simple removal of older package 
from higher (SiG's) repository would provide their users with updated 

A carefully listened to Mike when he said something like that kind of 
alerts is possible, to alert a builder of associated SiG that extra care 
is needed (tags?). He can correct me if I am wrong about alerts.

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

StarOS, Mikrotik and CentOS/RHEL/Linux consultant