On Wed, 15 Feb 2012 19:45:11 -0500, TH (Tom) wrote: > On Wed, 15 Feb 2012 23:40:22 +0100 > Michael Schwendt wrote: > > > Of course, a temporary staging repo would be needed. Filling it isn't > > trivial, however, and requires lots of iterations and a bullet-proof > > "--skip-broken" finder > > Huh? None of that junk is in updates today, that's why people > find it broken all the time. The test system using the staging > repo can either run "yum update" with no errors, or it can't. > If it gets no errors, the staging repo becomes the updates > repo. If it does get errors, the updates repo is left alone > until the staging repo gets fixed and everyone who pushed > an update since the last time updates was working gets mail > with the yum update transcript. > > Yes, that means nothing goes in updates if even one thing > is broken in the staging repo. But that is NOT a problem. Well, we can agree, if what you propose would happen at an earlier stage. To prevent broken deps in updates-testing already. With the added complexity that if any published package doesn't pass the testing and gets removed, any dependencies in other bodhi tickets must be removed, too. Bodhi then would refuse to accept any tickets, which break dependencies. That would imply that any push to stable could be free of broken deps, too, since it would only be a matter of resolving dependencies and adding the needed packages into the transaction set. Packagers could not simply publish incompatible library upgrades, for example, without publishing corresponding updates for dependencies on those libs. The update-testing request would need to be _complete_ before bodhi would accept it. Sort of an extra hurdle, however, and could be considered tiresome bureaucracy (because of the packager/advanced-packager model, where only the advanced-packagers are permitted to touch arbitrary packages and create bodhi tickets for them, too). So, I think it's a bug, if updates-testing contains broken deps and if packagers are permitted to keep such packages in updates-testing. Working on repositories, in which dependency breakage accumulates, gets increasingly troublesome. I'm not sure that would scale. It would need an environment where arbitrary packagers can alter all pending updates (to fix broken deps or to delete them) and trigger a new push to stable. Else it could become a pain to publish security fixes or packages with inter-dependencies on buildroot overrides. > Virtually everyone trying to run "yum update" with the current > process is getting errors and giving up till things work > anyway. I'm more concerned about the regular plea for help by those users, who don't just wait till updating works again. In replies, they receive wrong advice, such as enabling the updates-testing repo, running "yum clean all" (even if they use only the graphical package tools), or forcefully removing or reinstalling packages, which sometimes "fixes" the issue only because the repo has been fixed meanwhile. Or they don't get educated about the severity of the symptoms they see. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
