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