Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1503030 - [modularity] Default module install profile handling is incorrect
Summary: [modularity] Default module install profile handling is incorrect
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1478068
TreeView+ depends on / blocked
 
Reported: 2017-10-17 08:32 UTC by Nick Coghlan
Modified: 2018-03-13 08:07 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-13 08:07:27 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
dnf module install python2-ecosystem logs (deleted)
2017-11-07 09:26 UTC, Irina Gulina 		no flags Details
View All

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.
Note You need to log in before you can comment on or make changes to this bug.