Bug 1503030

Summary: [modularity] Default module install profile handling is incorrect
Product: [Fedora] Fedora Reporter: Nick Coghlan <ncoghlan>
Component: dnfAssignee: rpm-software-management
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 27CC: dmach, igulina, jmracek, mhatina, packaging-team-maint, rpm-software-management, sgallagh, 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-03-13 08:07:27 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    
Attachments:
Description Flags
dnf module install python2-ecosystem logs none

Description Nick Coghlan 2017-10-17 08:32:29 UTC
Description of problem:

The modulemd spec indicates an empty/non-existent default profile section should be treated as if it consisted of empty lists: https://pagure.io/modulemd/blob/master/f/spec.yaml#_100

That means a modulemd like the one for python3-ecosystem (http://pkgs.fedoraproject.org/modules/python3-ecosystem/blob/master/f/python3-ecosystem.yaml) should be permitted, with "dnf module install python3-ecosystem" being functionally equivalent to "dnf module enable python3-ecosystem" (i.e. it makes all the packages available for dependency resolution, but doesn't actually install any of them)

Version-Release number of selected component (if applicable):

dnf-2.7.3-1.module_e1d44a88.modularity.1.3fb9e5c.noarch

How reproducible:

Always

Steps to Reproduce:
1. docker run --rm -it jamesantill/boltron-27 dnf module install python3-ecosystem

Actual results:

Error: No such profile: python3-ecosystem:master:20171011080225

Expected results:

Same effect (and perhaps output?) as `dnf module enable python3-ecosystem`

Comment 1 Martin Hatina 2017-10-23 08:12:58 UTC
Fixed by https://github.com/rpm-software-management/dnf/pull/951

Comment 2 Irina Gulina 2017-11-07 09:26:49 UTC
Created attachment 1348876 [details]
dnf module install python2-ecosystem logs

Comment 3 Irina Gulina 2017-11-07 09:28:03 UTC
Martin, I still see this error for python{2,3}-ecosystem =( Please see the attachment in the previous comment.

Comment 4 Martin Hatina 2017-11-07 09:44:57 UTC
From /etc/dnf/modules.defaults.d/bikeshed.defaults:

[python2-ecosystem]
name=python2-ecosystem
stream=master
profiles=default

There is no 'default' profile in python2-ecosystem.

@Irina it is data problem.

Comment 5 Irina Gulina 2017-11-07 10:04:45 UTC
Stephan, please check whether we should move this BZ under fedora-modular-release component or create a new one on [1] and remove 'profiles=default', lines #142 and #152 from [2] or anth else. Thank you. 

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1503030#c2
[2] https://github.com/sgallagher/boltron-27/blob/master/base-27.defaults

Comment 6 Stephen Gallagher 2017-11-07 12:49:30 UTC
So there are definitely several bugs here which are interacting in an interesting way.

Bug 1: The fedora-release-modular package should not be setting a default profile for streams which don't actually have one. So this should be a new BZ and we should check through all of them, not just python3-ecosystem. (High priority)

Bug 2: The error message for the missing profile doesn't say which profile was requested (which would be obvious if the user had supplied it themselves, but if it's a bad default, we should indicate that clearly so it's easy for the user to identify the source of the problem). This will also result in bug reports if we ever accidentally or intentionally get out of sync between defaults and available profiles. (Medium priority)

Bug 3: IMHO, DNF should special-case the "default" profile and even if it is specified directly should always fall back to treating it as an empty list. This is because we have been implying that default should be always available and thus people *may* make this assumption in scripts, so we should work around it. (Medium priority).

Comment 8 Nick Coghlan 2017-11-09 05:35:35 UTC
As noted in the original bug report, https://pagure.io/modulemd/blob/master/f/spec.yaml#_100 says that if the "default" install profile is not listed in the modulemd file, that's the same as including it, but making it an empty list.

So there's nothing wrong with a modulemd file that doesn't define any install profiles - it's just saying "this is a pure content availability module for a commonly needed set of components used to satisfy dependencies from other modules".

Specific examples: python2-ecosystem and python3-ecosystem.

You're not supposed to install those directly with dnf, they just exist so we don't end up with 20-gajillion distinct builds of components like python-requests and python-jinja2.