Bug 1731033
Summary: | Mixed version of packages after module install the old version module when there are 2 version of modules | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | yalzhang <yalzhang> |
Component: | virt-rhel-module | Assignee: | Jeff Nelson <jen> |
Status: | CLOSED NOTABUG | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | unspecified | Docs Contact: | |
Priority: | medium | ||
Version: | --- | CC: | chayang, ddepaula, james.antill, jinzhao, juzhang, mblaha, psabata |
Target Milestone: | rc | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-08-05 18:25:13 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
yalzhang@redhat.com
2019-07-18 07:26:46 UTC
The command "yum module install virt:rhel:820190226174025" only installs packages mentioned in the profile in version described in virt:rhel:820190226174025. The dependencies are not covered like with other rpm operations (solver could pick anything that fulfil dependencies). To allow behaviour that you request, the number of packages in the profile should be extended to all packages in module, or dependencies of module packagies should requires exact version. Additionally the whole concept of modularity could be changed to provide a strict relation between module object and rpms. Unfortunately non of above solution can be delivered by DNF team, therefore I have to change the component. Please could you also provide information why the expected behaviour is important to you (user case behind is the most important part of the story)? Or is there other opinion from modularity team how to resolve the request? I'm strongly considering closing this as NOTABUG. I don't think a customer would find themselves in this situation: two separate repos, both with virt:rhel, but one that is newer than the other. As requested in comment 1, please provide a user story that explains why this configuration should be supported. It is the same with av virt module, like virt:8.0.0, and no need for 2 separate repos. Imagine that the customer only has single repo for 'latest' virt module, and they have virt:8.0.0 module installed and now comes the batch update, after they run "yum module update virt", the packages in the module will be mixed. But I'm not sure if this scenario could happen. Sorry to clear the needinfo in comment 2, add it back I would also suggest closing this as a NOTABUG. The weak link between RPMs and modules is there on purpose -- so that users can cherry-pick and lock specific NVRs if they so desire, even if that combination may not be supported by the module maintainer. As Jaroslav says, the installation is working as expected. If specific dependencies are required, they should indeed be either part of the profile or, even better, part of the RPM deps. Users can also update all packages by not using the 'module' command. Furthermore, the 'distro-sync' command can be used to install packages from the currently available content sources. >It is the same with av virt module, like virt:8.0.0, and no need for 2 separate repos. But it's not the same; your example scenario used two repos each containing virt:rhel. I understand your explanation but it does not apply in this case. >Imagine that the customer only has single repo for 'latest' virt module, and they have virt:8.0.0 module installed and now comes the batch update, >after they run "yum module update virt", the packages in the module will be mixed. But I'm not sure if this scenario could happen. It cannot. If it can, please open a bug report that illustrates this exact issue. Closing this BZ as NOTABUG. This scenario is not a valid use of virt:rhel and is not supported. |