Le mercredi 23 janvier 2013 à 20:02 +0000, Daniel P. Berrange a écrit : > If the deps provided by a new build have changed, then verify that > the change deps don't cause breakage. If they do, then do not allow > the new build into the rawhide target. Queue the build in some kind > of build specific 'pending' target. Let all the broken deps be fixed > in that pending target, and then atomically merge that target back > into rawhide target. Basically at no time ever, should you allow > broken deps to make it into rawhide. As long as our build process > allows for broken deps, then rawhide is going to be a trainwreck > of some kind or another. Requiring people to pre-announce deps breakage > to let people promptly rebuild has unequivocably failed to solve the > broken deps problems. We need to have a way to deal with this in our > build tool chain permanently without humans as the failure point. Not all breakages are equal. For example, something that break chroot creation should be avoided. Breaking critpath too ( rats-install and autoqa ). Holding 1 library (let's say ogre, because it was updated not so long ago) because 1 consumer of the library is not updated is gonna annoy the maintainer of the library. And while someone could fix the packages, not all packagers are coders, not all upstream are reactive. What about adding some timeout, or deciding that after a threshold of rebuilded packages, the packages are pushed from the tag ( provided this doesn't break chroot/critpath, of course )? So we do not hold rawhide for too long, yet provides enough protection for users against breakage. ( of course, this approach is full of subtle issues, what if 2 libraries break at the same time, what if I upgrade my package while on of the library is broken, etc ) -- Michael Scherer -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
