On Fri, 02 Jul 2010 20:12:26 +0200, Till wrote: > Btw. on a related issue:How do provenpackagers properly test for broken > deps manually? Every packager can [configure and] run repoclosure from yum-utils. Enable updates-testing, and optionally add a local repo for your own candidate builds. It should work with the default Yum configuration. > The case where two updates in updates-testing are > required to update one of them seems to me hard to ensure manually. But > when only one of both updates is pushed to stable, there will be a > broken dependency. I know that the fix is to bundle the builds of both > updates into one, but how is this tested? (I don't understand the question.) Ordinary test-updates cannot break other test-updates unless a koji buildroot override is involved. For updates without a koji buildroot override, only when an incompatible test-update is pushed to stable, it breaks dependencies of released packages outside updates-testing and also becomes available in the koji buildroot. So, you don't have anything like "only one of both updates is pushed to stable", because with a proper announcement of an incompatible update *and* communication about a koji buildroot override, all needed rebuilds should be known. Whether you let one packager put them all into the same bodhi ticket or have one packager push multiple tickets at once, is a process/documentation issue. There is no need to create bodhi tickets before all rebuilds are available, btw. For any update that isn't tested by the packager for incompatibilities with previous releases (e.g. using tools from the "rpmdevtools" package), so far it's important to not skip updates-testing and give me at least 24 hours to run extras-repoclosure (with stable test-updates entering nirvana until they become available in the updates repo, there is a window during which some packages are missing). For any incompatible test-update, the package dependencies it will break will be discovered. [About automating this during the push process, it is possible to have a depchecker simulate a --skip-broken and exclude packages which break dependencies. There are different strategies. However, the procedure must be backed up by strong policies, or else we will see broken deps whenever somebody skips the automated depchecking to push "something important".] -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
