Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1568165 - [modularity] assume the "default" profile exists even if it doesn't
Summary: [modularity] assume the "default" profile exists even if it doesn't
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 28
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Merlin Mathesius
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 1478068
TreeView+ depends on / blocked
Reported: 2018-04-16 21:47 UTC by Merlin Mathesius
Modified: 2018-08-28 14:15 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-07-24 11:26:54 UTC
Type: Bug

Attachments (Terms of Use)

Description Merlin Mathesius 2018-04-16 21:47:34 UTC
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):

How reproducible:

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:

Comment 2 Martin Hatina 2018-04-24 07:07:51 UTC
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.

Comment 3 Petr Šabata 2018-04-24 07:14:04 UTC
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.

Comment 4 Merlin Mathesius 2018-04-30 20:15:12 UTC
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.

Comment 5 Merlin Mathesius 2018-05-03 15:56:23 UTC

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