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.