On Sat, 03 Jul 2010 10:05:07 -0700, Adam wrote: > On Fri, 2010-07-02 at 18:24 +0200, Ralf Corsepius wrote: > > On 07/02/2010 06:20 PM, Will Woods wrote: > > > > > > > The main reasons we want to perform testing are things like: to avoid > > > pushing updates with broken dependencies, or updates that cause serious > > > regressions requiring manual intervention / emergency update > > > replacements. That sort of thing. > > > > > Should be done scripted as part of the "package push process". > > No need for karmas, no need for "provenpackager" > > 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 ? > (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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
