On 09/21/2016 03:08 PM, Honza Silhan wrote:

On Fri, Sep 16, 2016 at 5:02 PM, Petr Šabata <con...@redhat.com> wrote:
On Thu, Sep 15, 2016 at 10:59:55AM -0400, Matthew Miller wrote:
On Thu, Sep 15, 2016 at 02:25:52PM -0000, Mary Clarke wrote:
* enable vs install vs select

select is the worst :)

It's what I half-jokingly suggested during the last WG meeting :)

The reason was it's a verb we often use when talking about
modularity -- users "selecting" what modules they want on
their system.

Selecting/enabling/installing a module doesn't necessarily
mean something will get installed on your system.  I don't like
"install" much for that reason.

In the "enable" description is written: "Enable: enables the latest
version and/or release of a module and installs the rpms listed in the
default profile" so does it install something or not? Can you please
provide example when the module prepared for use does not need to be

There might be modules which contain just shared libraries which other modules would depend on. Such modules do not need to have any installation profile, so no RPM would be installed when the module is installed - the installation of its RPMs would be done as a result of dependencies from another module.

Even when there might be modules like that, I would personally vote for staying compatible with DNF subcommands as much as we can - so use "install". I presume that installation of majority of modules will result in some RPM being installed from the module. Modules which do not install any RPM during their installation are kind of special (like shared dependencies, shared services and so on) and they won't be installed by the end users in common cases.

I would personally start with list of DNF commands described here http://dnf.readthedocs.io/en/latest/command_ref.html and try to describe their Modularity equivalents similarly as Jan did in the last paragraph of his email I'm replying to.

Also keep in mind that when modules support is implemented in DNF it
will not be in conflict with the new terminology.  i.e. "dnf install
httpd" == enable httpd module == install rpms of httpd module. So
please reconsider "install" again.

* Install: performs actions to prepare modules to run

Is install a subset of enable, or does enable simply call install as a
convenience if you try to enable something that's not installed?

/me shrugs.

Until very recently, I thought install and enable were just
different verbs for the same action.  I don't really understand
what "install" means now either.  Could someone knowledgable

* Run: run the module

What does that mean? Do I *need* to run a module? Is this like "scl
enable"? And how does this interact with "enable", for that matter?


I would like to also hear what "install" and "run" means in module
terminology. It should be IMO explained before "enable" is decided to
be used as a reference word.

Would it be possible to provide more information about the commands
and in best case provide use cases for commands? Something like:
"Admin has module of version X installed. In the the same stream this
module has a security fix. Admin will use "check-upgrade" which will
..., then he will ... to ...

devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Jan Kaluza
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to