measuring success [was Re: Bodhi 0.7.5 release]

[Michael Schwendt]

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.