Bug 1465734
Summary: | rpmdeplint does not find conflicts between different versions of installonly packages (such as kernel) | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dan Callaghan <dcallagh> |
Component: | rpmdeplint | Assignee: | Miroslav Vadkerti <mvadkert> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | djc, fzatlouk, jorris, jpopelka, mvadkert |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | rpmdeplint-2.0~rc3-1.fc39 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2023-11-03 18:26:16 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dan Callaghan
2017-06-28 04:56:34 UTC
I did a bit of research to get to the bottom of how this works in libsolv, dnf, and yum... At the libsolv level, this magic: (In reply to Dan Callaghan from comment #0) > For a normal package, it doesn't matter if glibc-1 and glibc-2 both contain > the same file with different contains (indeed, it is very much expected) > because glibc-2 will replace glibc-1. is called "implicit obsoletes". That is, when you ask libsolv to install glibc-2 it implicitly obsoletes any other package with the same name. That causes glibc-1 to be replaced by glibc-2. The notion of "installonly" packages is purely at the yum/dnf level. Both yum and dnf have a config option to control the list of package names which are considered to be installonly, with the default list growing over the years but basically just covering the kernel. Specifically yum/config.py has the following defaults: 650 installonlypkgs = ListOption(['kernel', 'kernel-bigmem', 651 'kernel-enterprise','kernel-smp', 'kernel-modules', 'kernel-debug', 652 'kernel-unsupported', 'kernel-source', 'kernel-devel', 'kernel-PAE', 653 'kernel-PAE-debug']) whereas latest dnf/const.py.in has the following defaults: 28 INSTALLONLYPKGS=['kernel', 'kernel-PAE', 29 'installonlypkg(kernel)', 30 'installonlypkg(kernel-module)', 31 'installonlypkg(vm)'] The installonlypkg(*) names are virtual provides which the current Fedora kernel-core and kernel-modules packages provide, so this is the "modern" way to signal to dnf that a package is installonly. Presumably whoever invented the installonlypkg(*) virtual was intending that dnf would honour ANY value inside the brackets, but for whatever reason dnf only matches on those three particular strings. But anyway... In dnf the list of installonly packages from the config is passed down and set on the sack, and eventually ends up at the following code in construct_job() of hy-goal.c: 340 /* turn off implicit obsoletes for installonly packages */ 341 for (int i = 0; i < (int) dnf_sack_get_installonly(sack)->count; i++) 342 queue_push2(job, SOLVER_MULTIVERSION|SOLVER_SOLVABLE_PROVIDES, 343 dnf_sack_get_installonly(sack)->elements[i]); The SOLVER_MULTIVERSION action is what turns off the implicit obsoletes. According to libsolv-bindings.txt: *SOLVER_MULTIVERSION*:: Mark the matched packages for multiversion install. If they get to be installed because of some other job, the installation will keep the old version of the package installed (for rpm this is done by using ``-i'' instead of ``-U''). And the SOLVER_SOLVABLE_PROVIDES flag is because dnf wants to match the installonlypkgs against virtual provides like installonlypkg(kernel) not just literal package names. As far as how to handle this in rpmdeplint... In the conflict checking code, when we check if two packages can be installed together, we will need to add a job/goal to account for installonly packages, so that we correctly identify that two kernel packages *can* be installed together and therefore should *not* skip conflict checking. The fact that the set of installonly packages is actually configurable per system makes things difficult. It means we can't in general know whether any given package would be treated as installonly. But realistically, an end user cannot just blindly configure arbitrary packages to be installonly (for example if I set glibc installonly it just won't work because of the conflicts). Presumably the only reason this is configurable by end users is just to cover the case where the user has some package kernel-frobnoz from some third-party repository that they want to be treated *like* the kernel. In the old days of yum, manually adding kernel-frobnoz to installonlypkgs in yum.conf would have been the only way to make that work. The modern answer would be that kernel-frobnoz should add a virtual provide for installonlypkg(kernel) and then dnf will know to handle it correctly. So for rpmdeplint's purposes, we could just hardcode the union of all installonlypkgs that have been defined in dnf and yum (basically, all those variations of kernel-* plus the installonlypkg(*) virtuals). For completeness we could also add a command-line option --installonlypkgs=...,... to let the caller configure a different set, in case they are testing some third-party repo which has a kernel-like package. And maybe also --installonlypkgs-from-system to make it read the list from /etc/yum.conf, like the --repos-from-system option that we have. https://gerrit.beaker-project.org/5721 I didn't add any --installonlypkgs option for configuring the set of installonly packages, because I don't think it's really necessary. FEDORA-2023-a965252f36 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-a965252f36 FEDORA-2023-a965252f36 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-a965252f36` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-a965252f36 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2023-a965252f36 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report. |