On 09/21/2016 03:08 PM, Honza Silhan wrote:
Hi
On Fri, Sep 16, 2016 at 5:02 PM, Petr Šabata <contyk@xxxxxxxxxx> 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
installed?
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
elaborate?
* 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?
+1
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 ...
Honza
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Regards,
Jan Kaluza
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
