Bug 1654738 - hotfix repository content is not used when installing a module stream
Summary: hotfix repository content is not used when installing a module stream
Status: VERIFIED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: dnf   
(Show other bugs)
Version: 8.0
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: 8.0
Assignee: Jaroslav Mracek
QA Contact: Jan Blazek
URL:
Whiteboard:
Keywords: Triaged
Depends On:
Blocks: 1649352 1657676
TreeView+ depends on / blocked
 
Reported: 2018-11-29 15:01 UTC by Jan Blazek
Modified: 2018-12-19 12:03 UTC (History)
8 users (show)

Fixed In Version: dnf-4.0.9.1-1.el8
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Jan Blazek 2018-11-29 15:01:01 UTC
Description of problem:
Hotfix repository (with module_hotfixes=True) content is not used when user install a module via "yum module install". Only the original modular content gets into transaction.
Upgrading via "yum upgrade" applies the hotfix then.

yum module enable ModuleX:f26
yum module install ModuleX/default

Version-Release number of selected component (if applicable):
dnf-4.0.9-1.el8.noarch
libdnf-0.22.3-1.el8.x86_64
librepo-1.9.1-1.el8.x86_64

How reproducible:
Always

Steps to Reproduce:
Create custom hotfix repository with a package with higher NVR than in module.
Install a module via "yum module enable" and "yum install.

Actual results:
The package from hotfix repository is not installed.

Expected results:
The package from hotfix repository is installed.

Comment 3 Daniel Mach 2018-12-03 12:56:09 UTC
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.

Comment 4 Stephen Tweedie 2018-12-03 13:06:12 UTC
(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.

Comment 5 Daniel Mach 2018-12-04 15:28:21 UTC
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)

Comment 7 Stephen Tweedie 2018-12-05 16:32:43 UTC
(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

Comment 8 Stephen Tweedie 2018-12-05 16:38:11 UTC
(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.

Comment 10 Jaroslav Mracek 2018-12-05 20:58:05 UTC
> 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.

Comment 11 Jaroslav Mracek 2018-12-07 08:49:45 UTC
Proposed solution: https://github.com/rpm-software-management/dnf/pull/1285

Comment 12 Stephen Tweedie 2018-12-07 14:11:54 UTC
(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.

Comment 13 Karel Srot 2018-12-10 15:20:10 UTC
The alternative could be also to make hotfix repos module&stream specific.

Comment 14 Petr Šabata 2018-12-11 18:38:13 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.