Bug 1506486

Summary: [modularity] rpm install doesn't follow package versions from a locked module
Product: [Fedora] Fedora Reporter: Karel Srot <ksrot>
Component: dnfAssignee: Martin Hatina <mhatina>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: 27CC: dmach, extras-qa, jmracek, mhatina, packaging-team-maint, rpm-software-management, vmukhame
Target Milestone: ---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: 2018-03-13 08:03:38 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:
Bug Depends On:    
Bug Blocks: 1478068    

Description Karel Srot 2017-10-26 08:09:02 UTC
TestC-1-2.modA was installed while TestC-1-1.modA was expected due to a locked module profile version.

  Scenario: Having a locked module:stream I can still install and remove rpms for a locked profile version  # behave/module-lock-unlock-2-dnf-3.feature:32
    When I save rpmdb                                                                                       # behave/steps/rpm_steps.py:16
    And I successfully run "dnf install -y TestC"                                                           # behave/steps/command_steps.py:34
    And I successfully run "dnf remove --assumeyes TestD"                                                   # behave/steps/command_steps.py:34
    Then rpmdb changes are                                                                                  # behave/steps/rpm_steps.py:24
      | State     | Packages       |
      | installed | TestC/1-1.modA |
      | removed   | TestD          |
      Assertion Failed: Element counts were not equal:
      First has 0, Second has 1:  u'TestC-1-2.modA.noarch'

Comment 1 Martin Hatina 2017-10-27 06:55:14 UTC
Fixed by https://github.com/rpm-software-management/dnf/pull/971

Comment 2 Karel Srot 2017-10-27 09:08:54 UTC
tested with dnf-2.6.3-1.fc26.noarch

      shell.command.stderr:
      Traceback (most recent call last):
        File "/usr/bin/dnf-3", line 58, in <module>
          main.user_main(sys.argv[1:], exit_code=True)
        File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 179, in user_main
          errcode = main(args)
        File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 64, in main
          return _main(base, args, cli_class, option_parser_class)
        File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 99, in _main
          return cli_run(cli, base)
        File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 115, in cli_run
          cli.run()
        File "/usr/lib/python3.6/site-packages/dnf/cli/cli.py", line 1012, in run
          self._process_demands()
        File "/usr/lib/python3.6/site-packages/dnf/cli/cli.py", line 765, in _process_demands
          load_available_repos=self.demands.available_repos)
        File "/usr/lib/python3.6/site-packages/dnf/base.py", line 403, in fill_sack
          self._setup_modules()
        File "/usr/lib/python3.6/site-packages/dnf/base.py", line 198, in _setup_modules
          self.use_module_includes()
        File "/usr/lib/python3.6/site-packages/dnf/base.py", line 226, in use_module_includes
          self.sack.set_use_includes(True, repo.id)
      ValueError: Can't set use_includes for repo with given name.

Comment 3 Karel Srot 2017-10-27 10:24:59 UTC
sorry, dnf version should be dnf-2.7.5-8.fc26.modularity.1.3fb9e5c.git.8060.7666758None.noarch

Comment 4 Igor Gnatenko 2017-10-27 10:54:18 UTC
(In reply to Karel Srot from comment #3)
> sorry, dnf version should be
> dnf-2.7.5-8.fc26.modularity.1.3fb9e5c.git.8060.7666758None.noarch

I don't know where you've got this version... Latest version in F27 Modular Server is dnf-2.7.3-1.module_76d0cc8b.modularity.2.7493ec8

module_deadbeef part can be different, but that's a different story.

Comment 5 Igor Gnatenko 2017-10-27 10:56:14 UTC
https://github.com/rpm-software-management/dnf/commit/b5ba9b6ded63be94c1d109ca81ddceb72801694f

I've cherry-picked patch from master branch to fix this particular bug.

Comment 6 Karel Srot 2017-10-27 13:15:38 UTC
(In reply to Igor Gnatenko from comment #4)
> (In reply to Karel Srot from comment #3)
> > sorry, dnf version should be
> > dnf-2.7.5-8.fc26.modularity.1.3fb9e5c.git.8060.7666758None.noarch
> 
> I don't know where you've got this version... Latest version in F27 Modular
> Server is dnf-2.7.3-1.module_76d0cc8b.modularity.2.7493ec8
> 
> module_deadbeef part can be different, but that's a different story.

https://copr.fedorainfracloud.org/coprs/mhatina/dnf-modularity-nightly/build/654735/

We agreed to take latest copr builds if they are newer than what's in fedora-testing.

Comment 7 Karel Srot 2017-11-06 07:42:32 UTC
Tested with dnf-2.7.5-10.fc26.modularity.1.3fb9e5c.git.8068.798b9b1None.noarch
The traceback is gone, however still failing.

Comment 8 Karel Srot 2017-11-06 08:29:48 UTC
I have forgot to list some setup steps, complete scenario is as follows:

      Given I successfully run "dnf module enable ModuleA:f26"
        And I successfully run "dnf module install -y ModuleA:f26:1/minimal"
        And I successfully run "dnf module lock ModuleA"
       When I save rpmdb
        And I successfully run "dnf install -y TestC"
       Then rpmdb changes are
            | State     | Packages       |
            | installed | TestC/1-1.modA |

However TestC-1-2 is being installed as the package set is locked just to a stream but not a stream version.

Comment 9 Martin Hatina 2017-11-07 07:17:47 UTC
Fixed by https://github.com/rpm-software-management/dnf/pull/973

Comment 10 Jaroslav Mracek 2018-06-28 08:04:46 UTC
The issue is solved by dnf-3.0.1-1 that was released into rawhide.