Bug 191810

Created attachment 93276 [details]
yast2.tar.bz2

ZYPP_FULLLOG trace of second stage
until just after the 3 restarts I described.

I have the situation (or at least similar one) reproduced if anyone is interested...

Andreas, I'd say this is a blocker for releasing libzypp patch.

We don't understand why 2 libzypp patches are marked for update but no package they contain (we checked my logs, not Marcus' ones). Stefan, Klaus, could you look?

Created attachment 93281 [details]
screenshot

In the first run of YOU, libzypp + yast2-online-update patches were installed, than YaST restarted and shows this.

i saw the same during my tests, yes.

The logfiles does show only that 
libzypp-1715-0.noarch is installed and
U__s_[S2:0][patch]libzypp-1533-0.noarch
U__s_[S2:0][patch]libzypp-1715-0.noarch
are available and satisfied.
Do you have the logfiles for the screenshot ? 
( with ZYPP_FULLLOG=1 )

Created attachment 93284 [details]
my logfiles (without ZYPP_FULLOG, just in case they contain something interesting)

It looked strange that (in the second run) libzypp patches were marked with flag 
UI_s_ for transaction (532 Setting 'UI_s_[S3:0][patch]libzypp-1715-0.noarch
' to transact) in the ResolvablePreselectPatches call, while they have the II_s_[S0:0] flags just in following PkgSolve call.

It looks like rug is selected in the second run - and that's to be expected.

rug has a broken self-provides so is not updated with the first run.

The second run will just update rug since the new libzypp will handle it better.

but rug is selected in the _third_ run.

the _second_ run is totally empty. :)

No, AFAIU, the problem is that in second run, nothing is installed, and rug gets updated in the third run (you can see on the screenshot that rug is not selected for update)! At least this is what I think from Marcus's report, I didn't try to continue with my installation, hoping that leaving it in current state my help for some debugging.

OK, I can reproduce it in a running system.

Created attachment 93300 [details]
logfiles for screenshot of comment 4

The only different is that rug has been selected for update. Two libzypp patches are shown in the UI

Stefan, please read the comments #11 and #12. In the situation on screenshot, rug was not selected for update. And this situation is different from the one on running system, this is online update during installation, so I don't think it is reproducible on running system. Read also original mail on yast2-hacker: http://mailman.suse.de/mlarch//SuSE/yast2-hacker/2006/yast2-hacker.2006.07/msg00008.html

Thanks for the hints. Now I can reproduce it as you have described:

First solver run:
- The solver recognize the missing rug package and select it for installation.
  ( Update package]rug-7.1.1.0-18.i586 to package]rug-7.1.1.0-18.9.i586
- While the solver run we are deleting the old rug package and generate an 
  establish to the concerning atom:

  =====> 1st pass: [[Uninstall: I__s_[S0:0][package]rug-7.1.1.0-18.i586   
         (upgrade), Upgraded To U__s_[S3:1][package]rug-7.1.1.0-18.9.i586]]
         QueueItemEstablish (II_s_[S0:0][atom]rug-7.1.1.0-18.9.i586)
- In this Establish all dependencies are fullfilled cause the new rug package
  has been selected for installation:
  =====> 1st pass: [[Establish: II_s_[S0:0][atom]rug-7.1.1.0-18.9.i586]]
  itemIsPresent(<U_Ts_>U__s_[S3:1][package]rug-7.1.1.0-18.9.i586) Y
  all requirements of I__s_[S0:0][atom]rug-7.1.1.0-18.9.i586 met -> satisfied
  satisfy(I__s_[S0:0][atom]rug-7.1.1.0-18.9.i586:U_Ts_)

That means that the atom rug-7.1.1.0-18.9 has the status I__s_ for the next solver run and IS NOT more incomplete. So the concerning package rug-7.1.1.0-18.9 will not be selected for installation:

Install: UITh_[S3:0][patch]libzypp-1533-0.noarch, Upgrades II_s_[S0:0][patch]libzypp-1715-0.noarch, Explicit !]]
...
itemIsPresent<I__s_>I__s_[S0:0][atom]rug-7.1.1.0-18.9.i586) Y
requirementIsMet([atom] (namedcap) rug == 7.1.1.0-18.9) Y

So the error is that we are loosing the state "incomplete" in the rug atom.


====> it is an zypp bug

Created attachment 93442 [details]
logs with ZYPP_FULLLOG

How can [atom]rug-7.1.1.0-18.9 be installed (I__s_) while the dependant package [package]rug-7.1.1.0-18.9 is still uninstalled (U__s_) ?

This seems to me an aftereffect of the 'self-provides' from the original rug package.

Anyway, you can also enforce this situation if you delete the rug rpm with a simple "rpm -e rug" call after the patch has been installed.

*** Bug 194112 has been marked as a duplicate of this bug. ***

Stano? Could you please have a look and decide wheather you want to have this or not?

*** Bug 222517 has been marked as a duplicate of this bug. ***

i have so far not seen this phenomen with the test updates for 10.2.

It is simply to reproduce:
Install a patch; donwgrade a concerning package with a rpm call; updating a patch has no effect ( package will not be updated again )

*** Bug 228145 has been marked as a duplicate of this bug. ***

*** Bug 240286 has been marked as a duplicate of this bug. ***

The context of establishPool will be stored in Resolver and will be regarded for the next solver run everytime. So it will be not reset by any solver run anymore.
(revision 5026)

*** Bug 253998 has been marked as a duplicate of this bug. ***

*** Bug 253059 has been marked as a duplicate of this bug. ***

*** Bug 266491 has been marked as a duplicate of this bug. ***

*** Bug 234539 has been marked as a duplicate of this bug. ***

*** Bug 292844 has been marked as a duplicate of this bug. ***