Bugzilla – Bug 156513
laptop selection/pattern installes tpctl in any case
Last modified: 2006-05-04 08:21:44 UTC
linux:~ # uname -r 2.6.16-rc5-git9-2-smp linux:~ # rpm -qa kernel* kernel-smp-2.6.16_rc5_git9-2 kernel-default-2.6.16_rc5_git9-2 AFAIR i did a standard "SLP/NFS" installation of 10.1beta7 with KDE.
Created attachment 72014 [details] save_y2logs
Created attachment 72015 [details] hwinfo --all
OK it should not install this kernel on an Pentium II however I don't know if this is detected by YaST or just a matter of the package-selection. Jiri: Please provide a comment.
According to the logs, the kernel-smp package got there via a dependency chain: tpctl, Required by U_Tu_[selection]Laptop-10.1-17.noarch] This requires one of tpctl-kmp-*, solver selects tpctl-kmp-smp, which triggers the SMP kernel. Stefan, Klaus, could you, please, check that this assumption is correct and propose steps to fix this problem?
Ah, thats the -kmp problem. I suspected problems there before and asked for a testcase. Looks like we have this testcase now. Adding agruen to cc. The tpctl-kmp-* requirement should also be satisfied by tpctl-kmp-default ?! Normally, the solver tries to resolve with a minimum of installs/deletes. Needs further investigation of the logs.
Indeed, that's the "package1 pulls in package2-kmp" case. Your analysis is correct, and tpctl-kmp-default would have worked as well. When is kernel-$flavor added to the package list? Could it be that this happens only after the tpctl dependencies are resolved? This would explain the effect.
kernel-flavor is added as early as possible. What makes me real wonder is the heuristic of the solver finding the 'best' solution. It should prefer solutions with lesser package changes (installs/removes). Ideally, tpctl-kmp-* packages should add a hint in their dependencies (i.e. 'enhances: kernel-*' this would help the solver tremendously.
I can reproduce the error in a testcase. I will have a look concerning the "best solution"
Comment 7: We can easily add an Enhances tag to all KMP packages automatically. Are you sure this really helps the resolver, though?
At the current state of the solver, adding "enhances" is like leaving out the dependency, as all suggests/enhances are completely ignored. So don't do that... This looks more like a real bug of the solver, i.e. dragging in new packages even if the dependencies are already fulfilled.
Example enhances tags for Schubi: the tpctl-kmp-default package would include a tag `Enhances: kernel-default', and similarly for smp and the other flavors. In fact, the dependency between any whatever-kmp-$flavor and the associated kernel-$flavor package is strong, so we could as well add a `Requires: kernel-$flavor' tag to the KMPs. I don't see why this should be necessary though, because the whatever-kmp-$flavor packages already require a range of kernel(...) = ... symbols that only the corresponding kernel-$flavor packages can provide.
Enhances is totally wrong here. If tpctl-kmp-default contains "Enhances: kernel-default" the user would be asked to install "tpctl-kmp-default" if kernel-default is selected.
I have tested the required and had the same results as before;-( Perhaps there is another solution....I am saearching.
There was a bug in "It should prefer solutions with lesser package changes (installs/removes).". We are satified with this kind of solution priority.
comment #12. 'enhances' is indeed the correct hint to give in the package. 'supplements' would automatically drag in the package. 'enhances' could be used to help the solver. Its semantics do _not_ trigger any questions to the user. See http://svn.suse.de/trac/zypp/wiki/Dependencies
Just to clarify, the kernel module packages already Require symbols that only compatible kernel packages Provide, so the dependencies are already modeled correctly, and the issue here is the heuristic that picks the right solution from multiple possibilities. It doesn't seem that additional tags will help us reduce the solution space.
These tag certainly will help the solver since they are easier to evaluate and the solver will see them earlier.
The Wiki referred to in comment 15 describes SUggests and Enhances as follows: Suggests (Weak dependencies) Suggests are just hints for an application and not handled during dependency resolution. Kind of Amazon-style customers who bought this also looked at that Enhances (Reverse dependencies) A reverse suggests. This resolvable can be installed if this capability is provided by an installed resolvable. Its just a hint for an application. I.e. SuSEplugger can suggest packages for installation if a specific hardware is found. As I read this, both are only hints to applications (as opposed to the resolver), and the resolver doesn't care about them. Comment 10 interprets it the same way. So which meaning do these tags really have in the resolver? Assuming that kernel-default is already chosen, and each tpctl-kmp-$flavor has an `Enhances: kernel-$flavor' tag, how would that simplify the choice between the following resolver solutions: tpctl, tpctl-kmp-default tpctl, tpctl-kmp-smp, kernel-smp tpctl, tpctl-kmp-bigsmp, kernel-bigsmp Note again that each tpctl-kmp-$flavor package already has a `Requires: kernel-$flavor' tag meanwhile, but they already had a set of `Requires: kernel(name) = version' tags when this bug occurred, which were only fulfilled by the matching kernel. (We all know that the kernel-$flavor packages do not conflict with each other; otherwise we would have a single solution only.)
#15: No, Klaus. Enhances is wrong, you want 'Suggests', or even 'Requires'.
I'm still seeing this bug in Beta8. Will attach logs.
Created attachment 73133 [details] YaST2 logs for pete
*** Bug 156070 has been marked as a duplicate of this bug. ***
I can reproduce it in a testcase.
The first bug is, that selections does not have a source: 2006-03-16 12:13:36 <999> 10.10.103.12(3362) [solver] ResolverContext.cc(collectCompareInfo):1644 Version: [selection]Laptop-10-46.noarch[Source[0|undefined]{()}] --> cmpVersion : 0 2006-03-16 12:13:36 <999> 10.10.103.12(3362) [solver] ResolverContext.cc(collectCompareInfo):1663 Count of right Source[0|undefined]{()}: 3 2006-03-16 12:13:36 <999> 10.10.103.12(3362) [solver] ResolverContext.cc(collectCompareInfo):1629 Count of left SuseTagsImpl: 6 2006-03-16 12:13:36 <999> 10.10.103.12(3362) [solver] ResolverContext.cc(collectCompareInfo):1629 Count of left Source[0|undefined]{()}: 4 2006-03-16 12:13:36 <999> 10.10.103.12(3362) [solver] ResolverContext.cc(collectCompareInfo):1644 Version: [selection]Min-10-46.noarch[Source[0|undefined]{()}] Duncan could you please have a look on it ? But there is an additional bug in the solver
also in SLED10beta8. Logs needed?
No thank you. I have already a testcase for SLED10beta8 created. Duncan has fixed the sources and I have fixed the solver. Now it works for new installation with selections too. The testcases has only designed for updates.
This bug is far from fixed.
The solver still cannot tell when to pull in additional kernels and when not. Please tell me what I should put into kmp packages so that the resolver will resolve dependencies correctly.
The tpctl-kmp-<flavour> and madwifi-kmp-<flavour> (are there more ? Thats what I found in beta8 package lists) should ENHANCE the respective kernel-<flavour> package. Finally fixed in rev 2546 of libzypp. Submitted to autobuild.
Yes, there are several more in Autobuild. Does zypp correctly handle the case where such packages also require kernel-<flavor>? (I would guess so.)
Sure.
*** Bug 159585 has been marked as a duplicate of this bug. ***
FYI, I experienced this with SL10.1b8 on an IBM Thinkpad T42 (Pentium M) as well - see BUG#159797 (including a y2logs tarball). In my case it did not only install two kernel RPMs, but also picked the SMP kernel as the one to be used for booting. I don't think that's correct for a single-CPU Laptop :)
*** Bug 157669 has been marked as a duplicate of this bug. ***
For the record, we determined that Enhances does not help to solve this dependency problem, and that we the same mechanism as for language dependent packages (http://svn.suse.de/trac/zypp/wiki/Dependencies/Language) for modalias dependencies, so the modalias(<package>:<hardware_id>) syntax is now supported as well. This does not solve the tpctl, tpctl-kmp-flavor, and kernel-flavor case, though, as tpctl-kmp-* does not have modalias dependencies. For this case, we would need ``Supplements(and): kernel-flavor tpctl'', which doesn't exist in CODE10. Because tpctl requires tpctl-kmp, this problem only triggers when tpctl and when more than one kernel is installed/selected, which should be rare enough a case to ignore it, and accept that tpctl-kmp will not get selected automatically in this case. This is expected to get fixed in CODE11.
*** Bug 164147 has been marked as a duplicate of this bug. ***
Is this intended to be fixed in Build905? I still have kernel-default and kernel-smp installed. And of course tpctl-smp, which is also interesting in itself, as I do not have a Thinkpad.
Reopen, as per comment #39.
Need logs
Created attachment 77412 [details] yast logs
laptop.sel recommends tpctl so this package gets installed whenever laptop is choosen. This probably does not make sense. -> Assign to behlert, please review Then assign back to me to further investigate on install of multiple kernels
comments #15 and #17 are still valid. tpctl-kmp-<flavor> should enhance: kernel-<flavor> then the solver has a hint for the correct package. Andreas, please have kernel dependendant packages 'enhance' the corresponding kernel. There is currently no other way to hint the solver in the right direction.
I don't think this 'enhance' hack makes any sense at all. We already solved the problem with the modalias() hack, so why do anything else?
tpctl-kmp-default of SUSE-Linux-10.1-Build_907-i386 does not have any modalias() dependencies.
That's bad. If the user selects two kernels for installation, we want both of the corresponding tpctl-kmp packages to be installed. This won't work with the "enhances" hack, as the solver will only choose one solution. I think we really need a modalias() here so all of the tpctl-kmp packages get preselected.
Both solutions are equivalent. If multiple 'enhances' match, multiple providers are considered. However, only one(!) provider (of tpctl-kmp) will be finally selected. The modalias() is indeed better in this case, as multiple providers will be selected if multiple kernels are installed.
there is no modalias in these thinkpad modules: seife@strolchi:~> rpm -ql tpctl-kmp-default|grep ko | xargs modinfo filename: /lib/modules/2.6.16-8-default/updates/rtcmosram.ko author: Thomas Hood description: Driver for the RT CMOS RAM device on IBM ThinkPads license: GPL vermagic: 2.6.16-8-default 586 REGPARM gcc-4.1 depends: intermodule,thinkpad srcversion: 2911B29A7405A4073C8C2D2 filename: /lib/modules/2.6.16-8-default/updates/smapi.ko author: Thomas Hood description: Driver for the SMAPI BIOS on IBM ThinkPads license: GPL vermagic: 2.6.16-8-default 586 REGPARM gcc-4.1 depends: intermodule,thinkpad srcversion: 4318CFF433B16448BCCE7FC filename: /lib/modules/2.6.16-8-default/updates/superio.ko author: Thomas Hood description: Driver for the Super I/O chip on IBM ThinkPads license: GPL vermagic: 2.6.16-8-default 586 REGPARM gcc-4.1 depends: intermodule,thinkpad srcversion: A2B5F0C106980D116469065 filename: /lib/modules/2.6.16-8-default/updates/thinkpad.ko author: Thomas Hood description: Metadriver for IBM ThinkPad hardware drivers license: GPL vermagic: 2.6.16-8-default 586 REGPARM gcc-4.1 depends: intermodule srcversion: DA7BB55FD12F4B37D6857DB parm: enable_thinkpadpm:Enable/disable (1/0) use of the thinkpadpm module (i) parm: enable_rtcmosram:Enable/disable (1/0) use of the rtcmosram module (i) parm: enable_superio:Enable/disable (1/0) use of the superio module (i) parm: enable_smapi:Enable/disable (1/0) use of the smapi module (i) filename: /lib/modules/2.6.16-8-default/updates/thinkpadpm.ko author: Thomas Hood description: Driver for managing power on IBM ThinkPads license: GPL vermagic: 2.6.16-8-default 586 REGPARM gcc-4.1 depends: intermodule,thinkpad srcversion: A631412C9E2A143AAF5A591
The dependency we want to express for tpctl-kmp-$flavor is ``Supplements(and): tpctl kernel-$flavor''. We can neither express this dependency in CODE10 rpm, nor resolve it. A ``Supplements: modalias(package:alias)'' dependency cannot work for this case: there is no way to express that this package depends on two other packages. Abusing Enhances here makes no sense, either; according to the documentation, the resolver is not meant to consider Enhances at all. For CODE10, let's not implement this case, and to leave the package dependencies as they are now: tpctl Requires: tpctl-kmp tpctl-kmp-$flavor Provides: tpctl-kmp Requires: kernel(foobar) kernel-$flavor Provides: kernel(foobar) The resolver should then automatically select the tpctl-kmp-$flavor package that suits best (i.e., it matches the installed kernel). This will break down when installing multiple kernels with different flavors in parallel, but this deficiency is relatively small, and I think that users will be very unlikely to run into this case. The laptop selection/pattern/whatever should only select tpctl on Thinkpads. I don't know how this was implemented in CODE9, but this part should still be the same. In CODE11, we will probably be able to replace this with hal(...) dependencies, but we are not there yet, and this feature was rejected for CODE10.
The selection of the right tpctl-kmp-$flavor package could be done if the solver would compare sub-solutions. Then one solution would be 'cheaper' since it doesn't drag in an additional kernel. However the 'best' solution is computed by looking at the complete 'scenario' which seems to select tpctl-kmp-smp (comment #42) Adding enhances to the tpctl-kmp-$flavor package is right in every case. The (mis-)use of this in the solver is debatable. Lacking any better proposal, I'm assigning this bug to agruen for adding enhances for now. To be reconsidered later.
After discussing this with AJ, Klaus, and Harald, we decided that it is best to use the workaround Klaus described above at this point, for those KMPs that trigger this case. The affected packages [extracted by: #! /usr/bin/awk -f /^-Req:/ { req = 0 } /^=Pkg: / { pkg = $2 } req && /-kmp$/ { print pkg ": " $0 } /^+Req:/ { req = 1 } ] are: antivir-avguard: hbedv-dazuko-kmp bluetooth-alsa: bluetooth-alsa-kmp ipw3945d: wlan-kmp ndiswrapper: ndiswrapper-kmp pcfclock: pcfclock-kmp tpctl: tpctl-kmp zaptel: zaptel-kmp I have submitted fixed packages to STABLE.
IMO it would still make a lot of sense to debug the resolver's behavior and analyze why the resolver thinks that dragging in kernel-smp is cheaper than not dragging the additional kernel in. This is suspicious, and I would guess that this is a bug. The KMP packages are not the only ones where the resolver chooses between several alternatives, and we might run into the same bug elsewhere. We might not get that done for SL10.1, but we really should track down why the resolver ends up with the wrong/unexpected solution in this case.
not a blocker anymore.
*** Bug 165142 has been marked as a duplicate of this bug. ***
*** Bug 167581 has been marked as a duplicate of this bug. ***
apparently not fixed in RC1.
Logs please
Created attachment 79303 [details] yast2-logs Build 1003: Installer can't solve dependencies automatically -> conlict with tpctl.
Klaus, could you please have a look at this, as Schubi is on vacation?
comment #61: laptop selection requires tpctl which in turn requires tpctl-kmp. Solver chooses tpctl-kmp-default since it matches the selected kernel-default. However, kernel-default is x86_64 but tpctl-kmp-default is only available as i586. In the end, tpctl-kmp-default is not installable since its kernel dependencies cannot be fulfilled, e.g. kernel(vmlinux) == 73b8cba1c47dd165
Marcus, can you reproduce this with a clean install ?
Side-note: We will remove the tpctl package from the laptop seletion on x86_64 to avoid the conflict the mobile devices team as seen on x86_64 laptops. Fixed seletions will go into RC3.
we probably should not build and / or include the tpctl package on x86_64, but i do not know what side-effects this would cause.
autobuild removed tpctl from x86_64 and I have not heard further reports. Closing as fixed.