+++ This bug was initially created as a clone of Bug #1669527 +++

dnf-4.0.9-2.fc29.noarch

[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
Complete!
[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.

--- Additional comment from Jaroslav Mracek on 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.

--- Additional comment from Andrei Stepanov on 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"

--- Additional comment from Jaroslav Mracek on 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.

--- Additional comment from Petr Šabata on 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?

--- Additional comment from Jaroslav Mracek on 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?

--- Additional comment from James Antill on 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.

--- Additional comment from Adam Samalik on 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.

--- Additional comment from Jaroslav Mracek on 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.

--- Additional comment from Adam Samalik on 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.

--- Additional comment from Lukas Ruzicka on 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?

--- Additional comment from Lukas Ruzicka on 2019-03-27 11:07:52 UTC ---

Sorry about the mistake, of course the idea comes from Jaroslav and not Jaromir.