On Mon, 11 May 2009 23:03:01 +0200, Kevin wrote: > What happened is that people inadvertently built Qt-based packages which did > not require a rebuild and thus weren't on our radar against the Qt 4.5 > buildroot override, then pushed them to stable while Qt 4.5 was still in > testing That's no example for what Ralf has written: | Fact also is: "Testing" occasionally is the cause of broken package deps. As soon as the new Qt got tagged into the buildroot, *any* build done against Qt required coordination with you (or whoever decided when to release the new Qt and the known rebuilds). Even if the new Qt and the known set of rebuilds had been pushed directly to stable as quickly as possible, you could have missed builds done by other people. These builds would be mostly harmless if they go to updates-testing first. Not so for packages that go directly to stable. Treating the new Qt and the known rebuilds like hot potatoes is no solution for race conditions like that. Computer aided release management is needed. Especially if you say some packages segfaulted if not rebuilt. Push "all deps or nothing" from testing to stable: the new Qt and any builds done against it, but not a partial set of packages. Buildroot overrides that do more than just "poison the buildroots". Buildroot overrides that could tell the updates system to disallow Qt deps from being published before Qt. The Updates System taking into account the RPM inter-package dependencies, so a person who edits the Qt update request is shown the list of dependencies in the updates queue similar to bugzilla's "blocks/depends on" chains. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
