Bug 158446

Created attachment 73120 [details]
Logs, etc.

To clarify, this happens when both ftp://dist.suse.de/install/SLP/SUSE-10.1-Beta8/i386/CD1/ and /kmp-test2/1.1.1-default/update/ are registered as active install sources.

Installed
novfs-kmp-default-1.2.0_2.6.16_rc5_git14_2-7.i586
requires
kernel(kernel) == f422d0960a93a2a7
and
kernel(fs) == c1c864c12a011e1c
which are only provided by 
kernel-default-2.6.16_rc5_git14-3.i586

So the solver drags this in.

... and then it replaces it with kernel-default-2.6.16_rc6_git1-4, and we end up with broken dependencies for novfs-kmp-default-1.2.0_2.6.16_rc5_git14_2-7.

(The resolver afterwards also does not detect the broken dependencies in the rpm database when doing a dependency check. This might be useful, but it's not essential for installing/updating packages.)

If multiple versions of a package are found, is it possible to select a specific version to install? I don't manage to do that, but this would be useful. I don't understand why all the available versions of a package are grouped together in the GUI. (They probably always were in the past.)

Usually only one of multiple packages gets installed.
However, since kernel explicitly state that multiple version can be installed, there's not much we can do.

The same package (in a different version) gets updated twice in the same transaction,

  kernel-default-2.6.16_rc5_git14-2 =>
    kernel-default-2.6.16_rc5_git14-3 =>
    kernel-default-2.6.16_rc6_git1-4

so your explanation does not make sense to me, and this can only be a resolver bug.

Note that the kernel package updated last (rc6-git1) does not even fulfill all dependencies (as I wrote in comment 4), and so we end up with a broken system.

We could get screwed by this bug whenever more than one package is available in the installation sources while doing an update.

*** This bug has been marked as a duplicate of 157594 ***

Please note that simply filtering out packages as suggested in bug 157594#4 will not fix this bug: the installed package novfs-kmp-default-1.2.0_2.6.16_rc5_git14_2-7 is not compatible with kernel-default-2.6.16_rc6_git1-4, and it would still end up with broken dependencies.

Is this case handled properly? (Sorry about reopeneing.)

Stefan, please provide a testcase.

Andreas, where can I find:

/kmp-test2/1.1.1-default/update/
And could you make a dump of the rpm DB ?

~agruen/Export/kmp-test2/1.1.1-default
installed/ has the packages that are installed on top of Beta8 before the test, Neta8 and update/ are the active installation sources.

yast-tests/Bug158446-test.xml

returns:

>!> Requesting locale de
>!> Requesting locale de_DE
>!> Installing kernel-default from channel packages
>!> No problems so far
>!> Solution #1:
>!> upgrade kernel-default-2.6.16_rc5_git14-2.i586 => kernel-default-2.6.16_rc5_git14-3.i586[update]
>!> upgrade kernel-default-2.6.16_rc5_git14-2.i586 => kernel-default-2.6.16_rc6_git1-4.i586[packages]
>!> installs=0, upgrades=2, uninstalls=0

Lets look at the testcase:
Installed: kernel-default-2.6.16_rc5_git14-2.i586
Available: kernel-default-2.6.16_rc6_git1-4.i586 (GA repository)
           kernel-default-2.6.16_rc5_git14-3.i586 (Update repository)

In the testcase, the GA package is explicitly requested.
As the solver is coded to honor explicit requests, it tries to install this package (while keeping the system consistent)

So the current testcase does not show the normal behavior, since tools using zypp will choose the 'best' version available. However, it is also possible to request installation of a specific package, as shown in the testcase.

(Continuing investigation)

When installing a package, the resolver looks if another package with the same name is installed.
If this is the case, it handles the install as an update request. This will trigger an uninstall request for the installed package.

In the above case, an uninstall request for the installed 
kernel-default-2.6.16_rc5_git14-2.i586 is issued.

This breaks the dependency for the installed
novfs-kmp-default-1.2.0_2.6.16_rc5_git14_2-7.i586

So the solver tries to resolve the broken dependencies and finds
kernel-default-2.6.16_rc5_git14-2.i586 which satisfied the dependencies
of novfs-kmp-default.

It is certainly argueable if the uninstall request is the right thing to do for the kernel.
As kernels can be installed in multiple versions in parallel, it might be the right thing to treat kernel installs as pure installs (instead of upgrades).

-> needinfo. CC to autobuild expert ;-)

Comment 14: I did not select a specific version of the kernel in the GUI, I simple selected kernel-default for update. The GUI shows all available versions as one entry, and I simply clicked that. so I don't know how to select a specific version of a package; the radio button in the versions panel doesn't seem to work. So it might be a GUI bug; I don't know.

In any case, the resolver should figure out that it can't come up with a solution if kernel-default-2.6.16_rc6_git1-4.i586 is selected, and it should propose ways to resolve the resulting conflict.

comment #14: This is a gui bug.

comment #20: There is no dependency conflict and the resolver has no reason to report one

The resolver should know that updating the same package twice in a row won't result in both packages being installed. I guess that's what the resolver gets wrong. There are unresolved requirements of novfs-kmp-default-1.2.0_2.6.16_rc5_git14_2-7 in the system after the update, and that's a conflict the resolver should have prevented.

It does only one upgrade:
 install kernel-default-2.6.16_rc6_git1-4.i586
 remove (installed) kernel-default-2.6.16_rc5_git14-2.i586)

This leads to unresolved dependencies of 
novfs-kmp-default-1.2.0_2.6.16_rc5_git14_2-7.i586

These are fulfilled by the additional install of the second kernel.

As kernels are parallel installable, this creates no conflict.

If it only does one upgrade, than I don't know how the following entries end up in the y2log attached as part of comment 1, in this order:

Executing 'rpm' '--root' '/' '--dbpath' '/var/lib/rpm' '-U' '--percent' '--' '/kmp-test2/1.1.1-default/update/kernel-default-2.6.16_rc5_git14-3.i586.rpm'
Executing 'rpm' '--root' '/' '--dbpath' '/var/lib/rpm' '-U' '--percent' '--' '/var/adm/mount/AP_0x00000001/suse/i586/kernel-default-2.6.16_rc6_git1-4.i586.rpm'
Executing 'rpm' '--root' '/' '--dbpath' '/var/lib/rpm' '-U' '--percent' '--nodeps' '--' '/var/adm/mount/AP_0x00000001/suse/i586/kernel-default-2.6.16_rc6_git1-4.i586.rpm'

Apparently if a command fails, yast tries again with --nodeps. It is completely irrelevant whether or not kernels can be installed in parallel, we want to do an upgrade here.

Created attachment 74307 [details]
Same bug, reproduced on a STABLE system

There's indeed a dependency problem shown in this log. However, the current
Bug158446 testcase does NOT reflect the state of this system.

So please provide up-to-date testcases by
- make a dump of you systems rpm database as explained in
  http://svn.suse.de/trac/zypp/wiki/Testing/DumpRpmDb
- provide an _exact_ copy (or link) to the STABLE repository (the suse/setup/descr/packages file to be exact) you used for your test

Comment already provides all this information for the first instance of this bug, and the behavior hasn't changed at all since then. Please find the corresponding Beta 8 packages file at
/mounts/dist/install/SLP/SUSE-10.1-Beta8/i386/CD1/suse/setup/descr/packages

Created attachment 74316 [details]
System state of comment 26

This should be the system state for comment 26. (I have downgraded the kernel again).

Thanks. I'll recreate the testcase now. The current testcase data does not include the cloop-kmp-default package which indeed conflicts in the log of comment #26

The packages file mentioned in comment #28 and the one inluded in comment #29 are NOT identical. Which one did you use for testing ?

Again, there are two distinct test cases: the one in comment 1, which is based on Beta8, and the one in comment 26. Comment 28 belongs to the test case in comment 1. Comment s8 should have read "Comment 1 already provides...".

Yes, in the comment 26 test I have used three KMPs, two of which break due to this bug. The same bug also triggers in the comment 1 test case just the same.

I was able to recreate this in the testsuite.

The rpm errors you're seeing the the y2log are an rpm backend bug.
Kernels should be installed with '-I' but they are installed with '-U'.

So comments #15 and #16 still hold - in the solvers point of view.

y2log shows that the first rpm call, upgrade to kernel-default-2.6.16_rc5_git14-3.i586 succeeds since it fulfills the requirements of cloop-kmp-default and nvidia-glx-kmp-default.
This kernel was choosen by the solver.

The rpm errors are triggered by the second kernel upgrade stem from the fact that this is done with "rpm -U", effectively removing the just installed kernel.

Hmm, neither the packages file nor the YUM metadata flag the kernel as "rpm -I" (install_only). -> Bug 159933

There is no way for the solver to detect that the second install overrides the first. The is no defined installation order.
So it treats both installs as upgrades of the installed kernel.

However, duplicate installs of the same package name should be detected as "parallel installs" and flags them as errors.

Stefan (Schubi), can you debug why this wasn't detected as a parallel install ?

Klaus, is it still the testcase yast-tests/ Bug158446-test.xml which shows the parallel install ?

First of all
==============
The concerning code has been disabled:
    // if it's exactly the same package, ignore this request silently

    if (isParallelInstall( item )) {
	return true;
#if 0
	ResolverInfoMisc_Ptr misc_info = new ResolverInfoMisc( RESOLVER_INFO_TYPE_INSTALL_PARALLEL, item, RESOLVER_INFO_PRIORITY_VERBOSE );
	misc_info->setOtherPoolItem( getParallelInstall( item ) );
	addError( misc_info );
	return false;
#endif
    }

Second
========
This code is only in the install tree. If a package will be upgraded there
is no check concerning parallel installation. I have added.

Third
=======
There will be TRIED to install the package twice times. The complete log shows why. Have a look to the first line:


2006-03-21 22:48:32 <2> winden(4044) [target] TargetImpl.cc(commit):254 Install failed, retrying with --nodeps
2006-03-21 22:48:32 <1> winden(4044) [rpm] RpmDb.cc(doInstallPackage):1794 RpmDb::installPackage(/var/adm/mount/AP_0x00000001/suse/i586/kernel-default-2.6.16_rc6_git1-4.i586.rpm,8)
2006-03-21 22:48:32 <0> winden(4044) [zypp] ExternalProgram.cc(start_program):166 Executing 'rpm' '--root' '/' '--dbpath' '/var/lib/rpm' '-U' '--percent' '--nodeps' '--' '/var/adm/mount/AP_0x00000001/suse/i586/kernel-default-2.6.16_rc6_git1-4.i586.rpm'


So I have found two bugs although there has not been any bug at all.

As Klaus has already noted we cannot solve the other point, cause there is no conflict concerning the solver.

Lets come back to comments 19-21
The user selects a package. If there are more than one sources available I ( as  normal unser) would expect that newest version will be installed. It does not matter if it is the kernel or another package.
I assume that in 95 percent of all cases newer packages are "better" fulfill the dependencies than older versions. 
If there are still missing dependencies  we will install another package which fulfill the requirements. In that case an older version of a package. If these packages (older and newer version) does not conflict with eachother we will accept the installation.

So, can we guarantee that the UI will always select the newest version of package if there are more packages with different versions are available ?
Stefan, could you please check it ?
Or, would you like to have a call like "setInstallNewestVersion" ?

P.S.: Now the user will be informed by a solver-problem if there are more packages on different sources with the SAME version are available.

The UI will not select any version as a candidate unless the user explicitly does that in the "Versions" view. In almost all cases libzypp selects the candidate.

-> ma

Michl, has told me. If the user does not select a special candidate the solver will select the best architecture and then the best edition.
Anyway, we have changed the solver behaviour that parallel installation is not 
possible anymore without asking the user.
So i assume that I can close that bug.