Hello,
please could you tell me if any decisions have been made on how this thread is going to be handled? Is it defined somewhere, where I could read, what the behaviour will be like?
Thanks.
On Tue, Apr 2, 2019 at 3:19 PM Adam Samalik <asamalik@xxxxxxxxxx> wrote:
_______________________________________________On Tue, Apr 2, 2019 at 2:50 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:On Tue, Apr 2, 2019 at 3:36 AM Adam Samalik <asamalik@xxxxxxxxxx> wrote:
> When a packager doesn't provide the YAML defaults file at all, I'd assume it could have been unintentional and notified them about that fact. However, I wouldn't prevent the module to get to the compose or anything — just let them know so they can decide.
>
> How DNF should behave? Considering there is no default stream nor default profile, I'd suggest the following command to fail with an appropriate error message:
>
> $ dnf module install modulename:stream
>
> I'd strongly encourage DNF to suggest how to move forward, notifying the user there is no default profile defined for this module and that they either need to specify one in the install command:
>
> $ dnf module install modulename:stream/profile
>
> ... or to enable the module in order to consume the packages directly by the following command:
>
> $ dnf module enable modulename:stream
> $ dnf install packagename
>
> As Modularity is a new technology, I personally wouldn't be afraid of longer error messages — within reason of course — giving the user guidance.
>
Yeah, I think if no default object exists in the metadata, `dnf module
install modulename:stream` should probably not install anything and
instead prompt them to select a profile explicitly (ideally listing
the available options or suggesting `dnf enable modulename:stream`).
>>
>>
>>
>> === A module has explicitly set one or more of its streams to have no
>> default profiles ===
>>
>> This is a similar case to the above, except that a conscious choice
>> was made by the module maintainer to say that this module has no
>> reasonable default packages that could be selected. (For example, it
>> could be a collection of popular libraries that extend a particular
>> programming language, but there’s no obvious subset of them that makes
>> sense to install. It may exist and have streams solely because it
>> needs to be kept in sync with the interpreter version.)
>>
>> The open question is the same as the previous one: how should dnf
>> module install handle this case? In this particular example, it might
>> be more acceptable that it follows the enable fallback, since the
>> maintainer selected the lack of a profile explicitly. However, having
>> context-sensitive differences can be difficult for people to process.
>
>
> I assume the difference here is that the packager has provided the YAML defaults file, but haven't specified a default profile as opposed to not providing that file at all?
>
No, this is "the packager has provided a YAML defaults file like:
```
document: modulemd-defaults
version: 1
data:
modified: 201904020000
module: somemodule
stream: 1.0
profiles:
1.0: [ ]
```
See that the '1.0' stream is listed as having an empty set of default
profiles. Thus, a conscious decision has been made that no default
makes sense for this stream. What do we do here?
I'm leaning towards treating it like the above. DNF should provide a
helpful error suggesting available profiles or `dnf enable
module:stream`Ah, got it!Still strongly prefer consistent behaviour of this and the above — failing and giving the user a guidance.
> If that's true, I would strongly prefer consistency and fail on an install command without having a stream specified, and give the user guidance in an error message as above.
>
>>
>>
>>
>> === A module has a profile that contains zero RPMs ===
>>
>> In this case, a profile definition has been made in the module
>> metadata and it explicitly contains zero RPMs within it. Such an
>> example might be for compatibility: the module previously provided a
>> profile with that name that contained content, but it is no longer
>> doing so. Retaining the name may have been done to allow existing
>> scripts to avoid breaking. If we have a profile that contains zero
>> packages, should it be an error if we attempt to install it? If not,
>> what should the UX look like?
>
>
> This seams as a strange, yet possible choice for the packager to make.
>
> I do not have a strong opinion on this one. I'd probably suggest to not be too clever and let them have that choice, and make the install command work without installing any RPMs, and possibly emit a warning to the user about the fact.
Yeah, I'm leaning towards making a zero-package profile be a
validation error in libmodulemd.Actually, that sounds very reasonable.
>
>>
>>
>> [1] https://communityblog.fedoraproject.org/modularity-hackfest-march-2019/
>> _______________________________________________
>> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
>> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
>
>
>
> --
>
> Adam Šamalík
> ---------------------------
> Senior Software Engineer
> Red Hat
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
--Senior Software Engineer
Adam Šamalík
---------------------------
Red Hat
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
--
Lukáš Růžička
FEDORA QE, RHCE
Purkyňova 115
612 45 Brno - Královo Pole
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
