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