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 <asama...@redhat.com> wrote: > > > On Tue, Apr 2, 2019 at 2:50 PM Stephen Gallagher <sgall...@redhat.com> > wrote: > >> On Tue, Apr 2, 2019 at 3:36 AM Adam Samalik <asama...@redhat.com> 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@lists.fedoraproject.org >> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> >> 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@lists.fedoraproject.org >> > >> > >> > >> > -- >> > >> > Adam Šamalík >> > --------------------------- >> > Senior Software Engineer >> > Red Hat >> > _______________________________________________ >> > devel mailing list -- devel@lists.fedoraproject.org >> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> > 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@lists.fedoraproject.org >> _______________________________________________ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> 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@lists.fedoraproject.org >> > > > -- > > Adam Šamalík > --------------------------- > Senior Software Engineer > Red Hat > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > -- Lukáš Růžička FEDORA QE, RHCE Red Hat <https://www.redhat.com> Purkyňova 115 612 45 Brno - Královo Pole lruzi...@redhat.com TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
