Description of problem: While enabling a module, the user can only use an enum list ['default', 'development', 'minimal'] using anything else should result in an error Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. 2. 3. Actual results: Modules shouldn't get enabled Expected results: The user shouldn't be able to put random profile name and still enable the module in the first place Additional info: [root@localhost ~]# dnf module enable nodejs/bug Last metadata expiration check: 0:29:23 ago on Wed 28 Mar 2018 09:27:01 AM IST. 'nodejs/bug' is enabled [root@localhost ~]# dnf module enable nodejs:8/ada Last metadata expiration check: 0:29:56 ago on Wed 28 Mar 2018 09:27:01 AM IST. Enabling different stream for 'nodejs' Is this ok [y/N]: y 'nodejs:8/ada' is enabled [root@localhost ~]# dnf module enable nodejs:8/yummy Last metadata expiration check: 0:30:12 ago on Wed 28 Mar 2018 09:27:01 AM IST. 'nodejs:8/yummy' is enabled [root@localhost ~]# dnf module install nodejs/yummy Last metadata expiration check: 0:30:56 ago on Wed 28 Mar 2018 09:27:01 AM IST. Error: No such profile: nodejs:8:20180308143646/yummy. Possible profiles: ['default', 'development', 'min imal']
When doing `dnf module enable`, we should probably do one of the following: 1) Disallow the `/profile` suffix to the module. It's meaningless during the enable step anyway. So we could throw an error if it's provided here. 2) Warn that the `/profile` was superfluous and then indicate the the base module was enabled. 3) Assume this to mean that the user wanted this profile to become the default for the stream and automatically write out a modulemd-defaults file for it in /etc. I'm going to strongly recommend *against* 3, as I think we shouldn't be making implicit decisions about local default overrides. As far as the first two, I think 2) is probably the most user-friendly; it's informative but doesn't require them to retype anything.
Best will be to go with option #2 from comment #1. It is more user friendly than option #1.
Fixed in https://github.com/rpm-software-management/dnf/pull/1144