Comment 7 for bug 1071000

Revision history for this message
Marcin Banasiak (megabajt) wrote :

I think that it's not a problem with --test mode, but with depsolver.

In set #1 poldek should mark coreutils-8.19-1.x86_64,

In set #2 it doesn't mark mount for upgrade whereas it should. Unfortunately, I can't reproduce this locally, but I see in trace output that poldek claims that libmount is satisfied by db:

PROCESS mount-2.21.2-3.x86_64 as ORPHAN
: i3_process_orphan_requirements() mount-2.21.2-3.x86_64 as ORPHAN (nreqs=1)
: process_orphan_req() mount-2.21.2-3.x86_64, req: libmount = 2.21.2-3 (libmount = 2.21.2-3)
: i3_find_req() libmount = 2.21.2-3 not found (0 candidate(s), best=none)
: - satisfied by db
  libmount = 2.21.2-3: satisfied by db
: i3_process_orphan() END PROCESSING mount-2.21.2-3.x86_64 as ORPHAN

whereas it shouldn't according to i3_pkgdb_match_req() ("libmount = 2.21.2-3" is in ictx->unset and should be excluded from results). Below is shown how correct trace should look like:

PROCESS mount-2.21.2-3.x86_64 as ORPHAN
: i3_process_orphan_requirements() mount-2.21.2-3.x86_64 as ORPHAN (nreqs=1)
: process_orphan_req() mount-2.21.2-3.x86_64, req: libmount = 2.21.2-3 (libmount = 2.21.2-3)
: try_to_upgrade_orphan() mount-2.21.2-3.i686 req: libmount = 2.21.2-3 (satisfied=no)
: select_successor() mount-2.21.2-3.x86_64 (c=1)
: - 0. mount-2.22.1-1.x86_64 -> color 2, score 110
: select_successor() RET mount-2.22.1-1.x86_64 (for mount-2.21.2-3.x86_64)
: find_successor() successor of mount-2.21.2-3.x86_64 is mount-2.22.1-1.x86_64, marked=no
: try_to_upgrade_orphan() - mount-2.22.1-1.x86_64: upgrading orphan (upgrade resolves req)