Bug 1669527 - dnf module install <module> - just enable it, without installing it. [NEEDINFO]
Summary: dnf module install <module> - just enable it, without installing it.
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 29
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Jaroslav Mracek
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 1724564
TreeView+ depends on / blocked
Reported: 2019-01-25 14:31 UTC by Andrei Stepanov
Modified: 2019-08-31 01:38 UTC (History)
14 users (show)

Fixed In Version: dnf-4.2.5-4.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1724564 (view as bug list)
Last Closed: 2019-08-31 01:38:47 UTC
jmracek: needinfo? (psabata)

Attachments (Terms of Use)

Description Andrei Stepanov 2019-01-25 14:31:57 UTC

[root@host-8-244-145 ~]# dnf module install golang
Last metadata expiration check: 0:35:23 ago on Fri 25 Jan 2019 08:54:18 AM EST.
No default profiles for module golang:1.10
Dependencies resolved.
 Package            Arch              Version             Repository          Size
Enabling module streams:
 golang                               1.10                                        

Transaction Summary

Is this ok [y/N]: y
[root@host-8-244-145 ~]# 

As you can see from above, module was just enabled but not installed.

From man dnf:

       dnf [options] module install <module_spec>...
              Install module profiles incl. their RPMs.  In case no profile  was
              provided,  all default profiles get installed.  Module streams get
              enabled accordingly.

Comment 1 Jaroslav Mracek 2019-01-28 14:23:28 UTC
I know that this is confusing situation, but let me explain it. 

Profiles have name (master, default, broken) and could be set a default. If the profile is set as a default could be found using "dnf module list" command where after name of profile is label "[d]".

Due to confusing situation the profiles with name "default" will be renamed by infrastructure to something like "common" that more explain it.

Please if you want install profile that is not mark as default use following command:

"dnf module install golang/default"

Hope that it helped. Please if you think that module "golang" should have a default profiles, please reopen the bug and change component to golang or name of packages that are delivered by the module.

Comment 2 Andrei Stepanov 2019-01-28 18:09:24 UTC
As you can see: dnf module install golang
enables stream: 1.10 
This is Fedora 29.
Let's go and look what are default modules: https://pagure.io/releng/fedora-module-defaults/tree/f29
golang doesn't define default stream in Fedora 29.
Why stream "1.10" was enabled? It is not default, it wasn't specified explicitly.
dnf module install golang
should not enable stream "1.10"

Comment 3 Jaroslav Mracek 2019-01-29 08:06:41 UTC
We need an explanation from modularity team why this behavior is intended. Unfortunately there is no component, therefore I can only ask a needinfo.

Comment 4 Petr Šabata 2019-03-05 20:15:04 UTC
We discussed this during today's meeting.

There wasn't any agreement on how this should behave yet but I'll highlight some of the facts and scenarios:

* There are modules for which installation profiles don't make sense.  An example could be a building block module that is used as a shared dependency of other modules but isn't meant to be used on its own, or module that provides a resource bundle of tools or libraries.

* Such non-installable modules might not have default or any profiles.  If we mandate they have [default] profiles, those profiles could be empty.  What happens when we try to install those?

* We could through an error if the "install" action results in no content being installed, in general.  We could throw an error only if no profile is selected and tolerate empty profiles, being similar to groups with no mandatory packages.  We could emit explicit warnings or information messages about this or we could stay silent.

* How would QA (or the users for that matter) distinguish between packagers' intents and actual bugs where the modules is supposed to have a non-empty default profile but doesn't?

Comment 5 Jaroslav Mracek 2019-03-22 13:28:06 UTC
According to reporter request for change and additional discussion I would recommend to change the behavior as bellow:
For "dnf module install", when there is no "default" profile, no profile at all, or requested profile is missing, DNF must fail with an error and there will be no changes in module state. Do you agree?

Comment 6 James Antill 2019-03-26 16:08:32 UTC
Can you still create a default profile with no packages and not get the error message?
Otherwise you run into problems with removing packages from the default profile.

Comment 7 Adam Samalik 2019-03-26 16:11:57 UTC
Personally, I agree with you Jaroslav. It feels logical to me that the install command should either install RPMs, or to fail. Users can use the enable command make the module's packages available for direct consumption. The error message should hint that.

Comment 8 Jaroslav Mracek 2019-03-26 21:23:51 UTC
I would suggest:
1. An empty profile should not be allowed by infrastructure. Please set strict quality criteria for modular metadata. Please do not repeat mistakes with package groups (groups without mandatory and defaults packages).
2. dnf module install command should always require installation of profile, otherwise it should fail.

Comment 9 Adam Samalik 2019-03-27 08:05:01 UTC
> An empty profile should not be allowed by infrastructure. Please set strict quality criteria for modular metadata. Please do not repeat mistakes with package groups (groups without mandatory and defaults packages).

That's a fair suggestion for a policy, however, for DNF, we still need to expect this might happen as 3rd parties are likely to create their own modules outside our infrastructure. In such case, I would still prefer DNF to fail on the install command as no RPM packages would get installed.

Comment 10 Lukas Ruzicka 2019-03-27 11:05:21 UTC
Hello, I personally also have some problems with empty profiles and no defaults. Yesterday, we had a test day on Modularity and the majority of community testers expected that "dnf module install <module>" would actually install something. So I fully support Jaromir's proposals for a better user experience with modularity. I would be happy if modularity worked like this:

1) All modules have a default stream and profile, so "dnf module install <module>" would install the defaults and you can choose differently by using the :<stream>/<profile> statements.
2) If a module does not fulfil that requirement, it must not be installed nor enabled and the user should be informed about an error, most ideally such module cannot arrive in the repository unless ... (see 4).
3) The names of the profiles should not suggest that something is a default profile, if it is not.
4) If there is an absolute need for modules with empty profiles, or no default profiles, because someone needs them to build against them, they should not be listed in "dnf module list". They could be listed in "dnf module list --all", which would make sense to me. Currently, I do not see any difference between "list" and "list --all", and I think "list --all" is just a redundancy. If the modules were not listed by "module list" nobody would attempt to install them. In the "list --all", such special modules should be clearly marked so that users (and mostly QA people) now that this is an intention and do not file bugs.

What do you think?

Comment 11 Lukas Ruzicka 2019-03-27 11:07:52 UTC
Sorry about the mistake, of course the idea comes from Jaroslav and not Jaromir.

Comment 12 Jaroslav Mracek 2019-06-27 10:42:31 UTC
I create a patch that changes DNF behavior with module install command where in case that there is no default profile, dnf provides a hint about available packages ant then it raises an error (https://github.com/rpm-software-management/dnf/pull/1427)

I also provide an adjustments of current tests - https://github.com/rpm-software-management/ci-dnf-stack/pull/568

Comment 13 Fedora Update System 2019-08-14 07:23:57 UTC
FEDORA-2019-d4b6ede072 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-d4b6ede072

Comment 14 Fedora Update System 2019-08-16 20:12:20 UTC
dnf-4.2.5-4.fc29, dnf-plugins-extras-4.0.4-2.fc29, libdnf-0.31.0-6.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-d4b6ede072

Comment 15 Fedora Update System 2019-08-31 01:38:47 UTC
dnf-4.2.5-4.fc29, dnf-plugins-extras-4.0.4-2.fc29, libdnf-0.31.0-6.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

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