Description of problem: According to the modulemd specification, the default profile should be selected if no other input, be it from CLI or system configuration, is provided. dnf doesn't behave like that at the moment, always requiring a system config or the user to specify the profile to be installed on the command line. Version-Release number of selected component (if applicable): dnf-2.7.5-19.fc28.modularity.1.3fb9e5c.git.8118.7bc81fe.noarch How reproducible: always Steps to Reproduce: 1. fresh container based on docker.io/fedora:28 (or other current F28 VM/container) with latest F28 updates, fedora-repos-modular enabled, and latest patched dnf from COPR 2. dnf module info --profile flatpak-runtime:f28 # note no 'default' profile 3. dnf module install flatpak-runtime:f28 Actual results: Error: No such profile: flatpak-runtime:f28:20180307202408/default Expected results: No errors from module install request and module enabled, but no packages from module installed. Additional info:
We discussed this with S. Gallagher some time ago. There was an agreement that every module will have "default" profile, empty or not, but there will be one. This agreement should have resulted in modulemd.yaml spec to document it and libmodulemd to enforce the existence of "default" profile. But as I said it was some time ago and it could have been forgotten. Maybe it would be a good idea to reopen the discussion.
I consider this feature important. It provides greatly improves DNF UX by making it more forgiving to packaging errors. It also makes stack-style (no packages) or build block-style modules (no explicit profiles required in a normal use case) installable, again improving the UX. While anything can be changed, due to the reasons above I'd consider this a downgrade. Such a change would also introduce a format incompatibility and would require yet another version bump.
It has come to my attention that the original "Description of problem" text for this bug is incorrect and doesn't correspond to the title or other details. Fortunately, those commenting on this bug seem to have understood what was intended. For clarity, however, the description of this bug should read something like: Description of problem: According to the modulemd specification, the default profile is always to be assumed to exist. If it is not explicitly defined, the tooling should expect it to be empty. This is to provide a reasonable fallback and enhance the user experience.
https://github.com/rpm-software-management/dnf/pull/1077