This is a compromise to make `yum module install` work while/after switching a stream. Otherwise module install would keep existing packages at installed versions, because they're installed already.

I propose to move this to 8.1 and make it part of bigger design changes.

(In reply to Daniel Mach from comment #3)
> This is a compromise to make `yum module install` work while/after switching
> a stream. Otherwise module install would keep existing packages at installed
> versions, because they're installed already.
> 
> I propose to move this to 8.1 and make it part of bigger design changes.

We may have to, but I think we need to be very careful before deferring this, and give consideration to it as a potential blocker for 8.0.0.

It's a serious correctness error if "yum install" and "yum update" result in different packages being selected, and could easily risk user systems being incorrectly installed.

We have analyzed the issue in the "DNF/Modules cross-functional sync" meeting and agreed on following approach:


$ yum module install nodejs:10/default
    -> installed RPMs: nodejs-10-1 npm-6.4-1
hotfix repo is added to the system with nodejs-10-2
$ yum update
    -> updated RPMs: nodejs-10-2 (from hotfix repo)

1) EXISTING BEHAVIOR
$ yum module install nodejs:8/default
    -> installed RPMs: nodejs-8-1 npm-5.6-1
$ yum update
    -> updated RPMs: nodejs-10-2 (hotfix)

2) BEHAVIOR PROPOSED IN THE MEETING
$ yum module install nodejs:8/default
    -> unchanged RPMs: nodejs-10-1 npm-6.4-1
    the implementation of this behavior is to use install profile RPMs by NAME only, never use full NEVRA
    that will preserve hotfix on disk and don't reinstall it with package from the stream
    UX impact: impossible to explicitly install RPMs from an older module version (was never requested as a requirement, it's a side-effect that might be interesting for some users)
    UX impact: users will not get what they have asked for (install doing nothing in this case)
    proposed solution to the issue: don't allow stream change via module install

3) ANOTHER BEHAVIOR - ANALYZING (new, not discussed in the meeting)
$ yum module install nodejs:8/default
    -> unchanged RPMs: nodejs-10-1
    -> installed RPMs: npm-5.6-1
    We have discussed the issue in the DNF team and decided to look into
    implementing a behavior that would reinstall RPMs with the versions from
    the new stream while keeping the hotfixes on disk if they have higher version.
    If we don't have any solution and passing tests by end of the week,
    we'll proceed with implementing behavior 2)

(In reply to Daniel Mach from comment #5)
> We have analyzed the issue in the "DNF/Modules cross-functional sync"
> meeting and agreed on following approach:
...
> 2) BEHAVIOR PROPOSED IN THE MEETING
> $ yum module install nodejs:8/default
>     -> unchanged RPMs: nodejs-10-1 npm-6.4-1
>     the implementation of this behavior is to use install profile RPMs by
> NAME only, never use full NEVRA
>     that will preserve hotfix on disk and don't reinstall it with package
> from the stream
>     UX impact: impossible to explicitly install RPMs from an older module
> version (was never requested as a requirement, it's a side-effect that might
> be interesting for some users)

Would it be possible to do exact NEVRA-based when installing a specific module version, and name-based only when installing the implicit latest version for a stream?

I think it's fine to ignore hotfixes if you are explicitly asking for a particular old version of a module.  In that scenario, the user is clearly expecting to get a particular older version of a package, not necessarily the latest hotfix update.

Thanks,
 Stephen

(In reply to Daniel Mach from comment #5)

> 3) ANOTHER BEHAVIOR - ANALYZING (new, not discussed in the meeting)
> $ yum module install nodejs:8/default
>     -> unchanged RPMs: nodejs-10-1

Should that be nodejs-10-2 (the hotfix version)?
If so...

>     -> installed RPMs: npm-5.6-1
>     We have discussed the issue in the DNF team and decided to look into
>     implementing a behavior that would reinstall RPMs with the versions from
>     the new stream while keeping the hotfixes on disk if they have higher
> version.
>     If we don't have any solution and passing tests by end of the week,
>     we'll proceed with implementing behavior 2)

Fantastic --- I think this is the ideal best-of-both-worlds behaviour, but my understanding was it might be too complex to achieve quickly.  If it is possible, and results in behaviour consistent with "yum update" in all cases (it looks like it should,) it would be my preferred outcome.

> Would it be possible to do exact NEVRA-based when installing a specific module > version, and name-based only when installing the implicit latest version for a > stream?

The third behavior from comment 5 - even if I specify module version, I always use packages from module version + hotfixes for transaction goal. Then solver will pickup the best option (highest NEVRA). This behavior is even easy to explain to end user, because it always behave according to simple rule - hotfixes are always in.

Proposed solution: https://github.com/rpm-software-management/dnf/pull/1285

(In reply to Jaroslav Mracek from comment #10)
> > Would it be possible to do exact NEVRA-based when installing a specific module > version, and name-based only when installing the implicit latest version for a > stream?
> 
> The third behavior from comment 5 - even if I specify module version, I
> always use packages from module version + hotfixes for transaction goal.
> Then solver will pickup the best option (highest NEVRA). This behavior is
> even easy to explain to end user, because it always behave according to
> simple rule - hotfixes are always in.

Right, and that is usually the user's expectation --- *except* in the specific case where we are requesting a specific older version, in which case I would expect the higher NEVRA (even from hotfix) to be overridden by the version requested.

It might be easy to explain but it's still somewhat counter-intuitive and prevents rollback, so I would like us to consider that installing a specific module version should retain the ability to override hotfix.

The alternative could be also to make hotfix repos module&stream specific.

Discussed at today's interlock meeting.  Currently the behavior is undefined and is fine.  While we would prefer exact NEVRA installation, this can still be achieved by simply making the hotfix unavailable when choosing a specific version of a module.

We may request a change to this later but this is not required for 8.0.0.