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

[Ljubomir Ljubojevic]

On 01/24/2014 04:11 AM, Les Mikesell wrote:
> On Thu, Jan 23, 2014 at 6:51 PM, Ljubomir Ljubojevic <centos at plnet.rs> wrote:
>>
>>>>> The big question is whether there is a way to keep a dependent/related
>>>>> package from updating until everything has been tested together when
>>>>> the packages are managed independently in separate repos.
>>>>>
>>>>
>>>> If you compile package that depends on particular version:
>>>>
>>>> Requires: <deppackage1> = 0.8.1
>>>>
>>>> then yum will protest if you try to update newer deppackage1 package.
>>>> Error will appear, and until you satisfy it nothing will happen.
>>>
>>> Yes that could work, but it is not very efficient either.  It should
>>> be rare for the update to break things but doing that would force you
>>> to update every related package after testing just to let the
>>> dependency advance even if no changes are required.   Which again
>>> would make a flurry of traffic in the repositories and mirrors.
>>>
>>> --
>>
>> That is why I pushed for priorities. Everything is dynamic and
>> server/infrastructure/repository side and no package rebuilding, just
>> moving them little, and it should be possible to do it automatic
>> (protection) with git/koji. No amount SCL's and overthinking will beat
>> it's simplicity and universality.
>
> But won't that require duplicating the packages into all of the
> higher-priority repos?  Is there some magic with symlinks that would
> work to make it look like they were duplicated?
>

Not to ALL higher repositories. Remember they would be hierarchically 
structured, so you only need to put older package in repository ONE 
HIGHER then repository you are putting newer package into.

Links are very much possible, and are applied where ever possible. I do 
it on my own repository. I personally have a cron script that runs 
before mrepo and symlinks packages from several repos/directories to 
one. Physical solutions are many, depending on what is available.

You can keep older package in lower repository just adding new one and 
then symlink it to higher one. That is mostly done anyway, leaving one 
older version if regression is needed. Current examples in updates repo 
are resource-agents, perf, pacemaker, just run:

yum list \* --showduplicates --disablerepo=* --enablerepo=updates | grep 
x86_64

and check duplicated.

But there are circumstances making it easier:
1. packages coming to updates are not many, and SiG's will test them 
fast, so symlinks or packages can be removed in matter of days and only 
newly one created will be in line for testing.
2. SiG's will mark packages they are dependent of. There is no need that 
Xen SiG has to watch "named" package, so only those SiG's depending on 
functional "named" package (just a simple example) will mark it, will be 
informed of new version (as soon as it hit's git.centos.org or when it's 
srpm appears on CentOS of even RHEL file servers), and will get a 
copy/symlink of older package.
3. Many important packages (for SiG's) will already be replaced with 
newer version, so those packages will not be marked and will not need 
any special attention, so business as usual.
4. Every change is logged in Change_log, so maybe on-duty SiG 
representative can clear package even before actual release to updates 
folder.
5. When new distro version is releases, Q&A anyhow tests everything, so 
you can forget that scenario needing this mechanism. Only packages 
coming to updates repo would be marked, IF they are of interest to SiG's.

Another system can be put in place. Every stable repository will have to 
have testing repository. So newer package could be symlinked/copied 
automatically to testing repository of SiG/Variant and Variants/SiG's 
could have a testing VM with enabled testing repository. So as soon as 
newer package is released, testing VM could pull new packages and checks 
would be performed, manual or automatic.

So SiG/Variant would greenlight the newer package much faster then if 
they do it all by hand. As soon as they greenlight the package, older 
version would be automatically removed from stable repo, newer package 
from testing repo and createrepo run would allow everyone using Variants 
to update to new package. If there is a problem, SiG would decide what 
needs to be done, but until permanent solution is found, this 
problem-suppression system would safeguard Variants PR and business 
model, just like they are doing everything on their own.

Anyone, if you can think of any other problematic scenario, feel free to 
put this construct of mine to the test.

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

StarOS, Mikrotik and CentOS/RHEL/Linux consultant