On Mon, Apr 1, 2019 at 6:58 PM Stephen Gallagher <sgall...@redhat.com> wrote:
> Last month, we had a Modularity Hackfest in Boston. I wrote up a > hackfest report at the Community Blog[1] back then, which included > several open questions related to how to handle stream and profile > defaults. I'm reprinting them here on Fedora Devel for public input. > > == Open Questions == > We had some discussions throughout the course of the hackfest that > didn’t reach a clear consensus. The most contentious was around what > to do about empty profile data. There are several uncommon cases that > need to have clear UX decisions made around them. > > === A module does not have one or more of its profiles specified to be > the default. === > > The module creator has not provided a defaults object into the YAML > (in Fedora, this is done by requesting it be added by release > engineering or submitting a pull request to the fedora-module-defaults > repository). This may be intentional or unintentional. Fedora QA has > asked us if they should be treating the lack of a defaults reference > for the profile as a failure, since this is something that could be > detected during post-compose testing and reported. My personal opinion > on this case is that for modules in Fedora itself, we should indeed > treat this as a bug and require that all modules have a defaults > object that properly references a set of default profiles for any > stream included in that compose. > The open question here is what the DNF experience should be if dnf > module install modulename:modulestream is called. The current behavior > is that DNF treats this as equivalent to calling dnf module enable > modulename:modulestream (it makes the contents of this module > explicitly available, but installs nothing at that time. Feedback from > users of the RHEL 8 Beta have indicated that this is an unexpected > behavior of the install verb. They’d prefer to see DNF report an error > if install is called and results in no packages being installed. In > part, this is because it would be silently hiding the possibility that > the defaults are missing. > 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. > > > === 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? 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. > > [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
