Bug 1669527

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.

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"

We need an explanation from modularity team why this behavior is intended. Unfortunately there is no component, therefore I can only ask a needinfo.

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?

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?

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.

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.

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.

> 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.

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?

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

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

FEDORA-2019-d4b6ede072 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-d4b6ede072

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

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.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days