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`
Fixed by https://github.com/rpm-software-management/dnf/pull/951
Created attachment 1348876 [details] dnf module install python2-ecosystem logs
Martin, I still see this error for python{2,3}-ecosystem =( Please see the attachment in the previous comment.
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.
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
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).
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.