On Mon, Apr 1, 2019 at 6:58 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> 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@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
---------------------------
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
