On Sat, 2010-07-03 at 20:40 +0200, Michael Schwendt wrote: > > That only handles a subset of the 'broken dependencies' problem. We've > > already had an example this year of a dependency issue the proposed > > autoqa depcheck test wouldn't catch, and Michael's script didn't - the > > nss-softokn update > > Which one was that? > https://bugzilla.redhat.com/596840 ? Yep. > > (as the broken dep is only apparent if you take into > > consideration multilib issues and which repositories will have which > > updated packages available). > > There are multiple problems: > > * Upgrades from F12 to F13. The depcheck for F13 would need to enable F12 > repos _always_ - to catch upgrade path violations that lead to dependency > problems. I only do this a few times shortly before the release of FN+1 > (=F13). > > * Yum depsolving behaviour on systems where multiarch packages are > installed and an update isn't multiarch anymore. For example, where Yum on > x86_64 would pull in lots of i686 packages to resolve dependencies, that > would be considered a problem by the user but not by a depchecker, because > there are no unresolvable dependencies to detect. Unless you teach the > depsolver (and depchecker) that cross-arch dependencies are something > to report as a problem. That would be more than "repository closure". > The depchecker doesn't look for file conflicts either. There could be a > dependency chain, which doesn't suffer from unresolvable deps but from > implicit file conflicts. Yep, indeed. I'm really not criticising the script. I'm just pointing out that we know there are some pretty complex scenarios out there which we haven't yet figured out how to test in an automated way; I'm challenging the assumption that we can write a perfect depcheck test which will ensure there is never a dependency issue ever again. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
