Bug 1568165

Summary:	[modularity] assume the "default" profile exists even if it doesn't
Product:	[Fedora] Fedora	Reporter:	Merlin Mathesius <mmathesi>
Component:	dnf	Assignee:	Merlin Mathesius <mmathesi>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	28	CC:	dmach, mhatina, packaging-team-maint, psabata, rpm-software-management, vmukhame
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-07-24 11:26:54 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1478068

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):
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:

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

https://github.com/rpm-software-management/dnf/pull/1077