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