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

[Ljubomir Ljubojevic]

On 01/23/2014 12:32 AM, Les Mikesell wrote:
> On Wed, Jan 22, 2014 at 5:15 PM, Ljubomir Ljubojevic <centos at plnet.rs> wrote:
>>
>> If automatic copy to SiG's repository is possible, or maybe for Core
>> devs to copy it them selves manually would do it.
>>
>> And I have not said Core repo would hold back updates until everyone
>> test it. Please read more carefully, because I said COPY CURENT TO SIGS
>> REPOSITORY AND THEN PUBLISH UPDATE, so nothing is broken on systems
>> using SiG's repository. I hope this was more clear explanation.
>
> I understood what you meant, but my question is about the mirroring
> infrastructure.  Personally I'd like to see dozens if not more 'ready
> as installed' respins for different purposes.  If you have to push all
> the base packages (or even a lot..) into the respin's specific update
> repo as the only way to control what yum will do, won't that add a
> huge burden to the repo mirroring infrastructure as all those copies
> have to replicate?  Or if you look at it from the other direction,
> could there be a better way of telling yum when to update a package
> than keeping newer things out of all of the repository it uses?
>

Bare in mind we are talking here only about newly emerged issues, 
because if SiG has had a problem with some package in the past, chances 
are that modified version is already in higher SiG's repository.

Lets go back a little. RHEL packages mostly and mainly are built so 
there are NO drastic changes. Every update must provide exactly the same 
behavior. I am not knowledgeable about this, but I would think that Red 
Hat warns it some package changes it's behavior? Changelog in rpm's 
would be an indication of made changes, right?

So I do not expect large number of "dangerous" packages.
1. SiG's would mark any upstream/Core package they depend on
2. rpm can be limited to max version allowed, so if newer version is 
available, update of that new package, on a system with SiG's package 
having that limit, would not be possible.

Where you are thinking of huge number of largely different packages, I 
am thinking of majority of updates being minor bug fixes and large 
number of packages only with new distro version, 6.4->6.5->6.6, etc.

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

StarOS, Mikrotik and CentOS/RHEL/Linux consultant