On Sat, Jul 03, 2010 at 12:27:50PM +0200, Michael Schwendt wrote: > 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. This is not true, because there can be runtime dependencies on another update in -testing that is not build dependency, e.g. if an python app requires a newer version of a python module. > 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. Just requiring proper communication will lead to failure, because e.g. new maintainers might not know some of these problems and autokarma pushes one of the dependent updates to stable but not the other. And this already happened with a highly used package. Also Bodhi does not allow to fix updates by other people than the update submitter afaik. Also it is not possible to e.g. add my new package to some other update to ensure atomicity. E.g. when I wrote fedora-easy-karma, it needed a version of python-fedora that was only in updates-testing. But there was no easy way for me to ensure in Bodhi that f-e-k will only be pushed to stable after the python-fedora update. The only supported way other than ensuring it manually is to ask the python-fedora update submitter to include the f-e-k build. But then all changes wrt to the f-e-k build need to be proxied through the python-fedora submitter, which just means double work. And it also means that for the manually method I need to ensure that autokarma is off, but it also tries to re-activate itself with every update edit. Regards Till
Attachment:
pgpI9TBEcG5bg.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
