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

[Les Mikesell]

On Fri, Jan 24, 2014 at 5:56 AM, Ljubomir Ljubojevic <centos at plnet.rs> wrote:
>
>> 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.

Sure you could do this yourself, and it might be a solution for my
long-standing complaint about needing frozen repository mirrors in
states of every update you might want to repeat.   But, will it be
supported across all the existing mirror infrastructure?

> 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.

I think that is being optimistic.  Think about the number of updates
that come in a minor revision update.

> 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.

Packages get renamed/split/merged and dependencies added in minor-rev
updates.  Not sure you can count on existing naming.

> 4. Every change is logged in Change_log, so maybe on-duty SiG
> representative can clear package even before actual release to updates
> folder.

I wouldn't want to restrict SIGs to organizations able to guarantee that.

> 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.

I like this, but it depends on the mirror mechanism playing nicely
with symlinks - everywhere.   In this scenario you could just symlink
everything and point the base updates at the SIG, pretending
everything was duplicated.   And you wouldn't need priorities.

-- 
   Les Mikesell
     lesmikesell at gmail.com