Hide Forgot
Description of problem: Mixed version of packages after module install the old version module when there are 2 version of modules Version-Release number of selected component (if applicable): dnf-4.0.9.2-5.el8.noarch yum-4.0.9.2-5.el8.noarch How reproducible: 100% Steps to Reproduce: 1. Enable or reset 2 versions for the same stream of a module; # yum module list virt ...... ** 800_app ** ====> the lower version with version "820190226174025" Name Stream Profiles Summary virt rhel [d][e] common [d] Virtualization module ** rhel_new ** ====> the higher version Name Stream Profiles Summary virt rhel [d][e] common [d] Virtualization module Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled 2. Install the lower version of module; check the packages in the profile are from the lower version module, but some dependencies are from the higher version module, the packages will installed are mixed. # yum module install virt:rhel:820190226174025 ==================================================================================================================== Package Arch Version Repository Size ==================================================================================================================== Installing group/module packages: libguestfs x86_64 1:1.38.4-10.module+el8+2709+40ed2f2c ** 800_app ** 2.8 M ====> the old version libvirt-client x86_64 4.5.0-23.module+el8+2800+2d311f65 800_app 326 k libvirt-daemon-config-network x86_64 4.5.0-23.module+el8+2800+2d311f65 800_app 26 k libvirt-daemon-kvm x86_64 4.5.0-23.module+el8+2800+2d311f65 800_app 24 k Installing dependencies: libvirt-bash-completion x86_64 4.5.0-23.module+el8+2800+2d311f65 800_app 25 k ...... libvirt-libs x86_64 4.5.0-23.module+el8+2800+2d311f65 800_app 4.1 M **************************** Below dependencies are from the new rhel module ************************************** qemu-img x86_64 15:2.12.0-64.module+el8.0.0.z+3418+a72cf898.2 ** rhel_new ** 916 k ====> the new version qemu-kvm x86_64 15:2.12.0-64.module+el8.0.0.z+3418+a72cf898.2 rhel_new 68 k qemu-kvm-block-curl x86_64 15:2.12.0-64.module+el8.0.0.z+3418+a72cf898.2 rhel_new 78 k qemu-kvm-block-gluster x86_64 15:2.12.0-64.module+el8.0.0.z+3418+a72cf898.2 rhel_new 81 k qemu-kvm-block-iscsi x86_64 15:2.12.0-64.module+el8.0.0.z+3418+a72cf898.2 rhel_new 86 k qemu-kvm-block-rbd x86_64 15:2.12.0-64.module+el8.0.0.z+3418+a72cf898.2 rhel_new 80 k qemu-kvm-block-ssh x86_64 15:2.12.0-64.module+el8.0.0.z+3418+a72cf898.2 rhel_new 80 k qemu-kvm-common x86_64 15:2.12.0-64.module+el8.0.0.z+3418+a72cf898.2 rhel_new 899 k qemu-kvm-core x86_64 15:2.12.0-64.module+el8.0.0.z+3418+a72cf898.2 rhel_new 2.9 M **************************** Above dependencies are from the new rhel module ************************************** Installing module profiles: virt/common ...... Actual results: The packages will be mixed after module install Expected results: The packages should not be mixed after module install Additional info: 1) only enable the old version repo, install the old version virt module, then it will not be mixed; 2) enable the new version repo, run "yum module update", only the packages in the profile can be updated, the other packages in the module can not be updated, so the packages are mixed after update. There is an explanation in the man page: "dnf [options] module update <module-spec>... Update RPMs in installed module profiles. In case no profile was provided, all installed profiles get updated." But I think it is not enough, all the packages should be updated as "The virt module is designed to formally couple those components that have a strong dependency between them. This is to ensure the components stay in sync with each other"
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.