[archived] Boltron Feedback¶

How do you like the following commands?¶

Please rate the following commands in terms of backwards compatibility.¶

Anything else about the install syntax?¶

• The “automatic module or package” syntax overriding the original “dnf install httpd” is BAD. At least there MUST be a new “dnf package install httpd” for those that know they want to install a package and not a same-named module.
• Please do not reuse same sintax for modules.
• Dnf install_module httpd clarity and auto-completion. Or make modules and package names unique httpd-module
• dnf install-module httpd
• it is confusing of what is happening.
• I think it should be clear if one installs a package or a module. Groups could be considered the same as modules, though.
• Please keep current behaviour, “dnf install httpd” shall install the package. There may be added a “dnf package install” and make the previous one configurable.
• Actually, I thought you will ‘enable’/disable a module rather than ‘installing’/removing it! :P
• Clear differentation between module and regular package. Consider ansible/chef/puppet use cases too
• Someone may get a modular package when they want just the most current.
• You’re in a losing battle here. You can’t reuse syntax without tripping up existing work flows but adding new syntax is just annoying. I think it needs to be obvious it’s not a ‘standard’ install, but I don’t think you can reuse group nomenclature.
• It should be possible to install both modules and packages in a single yum/dnf command.
• I think that since there are existing users, we shouldn’t overload them with significantly different functionality.
• I think ‘dnf install $package’ makes sense for base packages ie. kernel images, kernel headers, kernel modules, shells. ‘dnf module install $package’ makes more sense for applications such as mariadb, postgres, httpd, php, etc.

Only one stream of a module can be installed at a time. How do you like this decison?¶

Anything else about “Only one stream of a module can be installed”?¶

• It would be better if multiple versions are allowed, but I didn’t think of the best way to run one over the other.
• It’s common to need to test against a stable and development version side by side.
• wondering about the case where other components might need different streams of a module together (for example, openshift needs docker-1.12.6 and something else needs docker-1.13, has that been accounted for? (IIUC, docker in this case would have 2 streams 1.12.6 and 1.13.1, is that right?)
• parallel installable modules (like scl?)
• it should be possible to install several and allow easy switching, much like alternatives would do
• We should have something like Software Collections, or Python virtualenv, i.e., streams which we can activate or de-activate at will
• This is hard to answer without better examples about modules. How does it work with e.g., language versions? Can you parallel install two Python versions like this?
• Always with “dnf module install” … or configurable but not by default
• I’d not like to have this limitation as a design decision. I prefer if tools (dnf/rpm) allow for installing packages from different streams of a module simultaneously. It should fail naturally if those packages have file conflicts, but if not, it should work fine.
• I thought it was said you could have both apache-2.4 and 2.6 at the same time in one of the examples given…
• What’s the purpose of differentiating if only one can be installed at a time? What makes this any different than an RPM pinned to a specific version?
• It would be too complicated to install multiple streams in parallel.
• If I am trying to do A-B testing.. do I need two different systems. One with the new version of say wordpress-old and another with wordpress-new?
• Ideally, the streams would be parallel installable. However, this might not be technically possible in all cases. Parallel installability is hard.
• Ideally you would be able to do multiple streams, but for most use cases it shouldn’t be an issue.
• it’d be nice to be able to run httpd-stable and httpd-current at the same time

How do you like using the install command to switch streams?¶

Anything else about switching streams?¶

• Is this going to warn me that I’m switching streams? Presumably, the older stream will be uninstalled, right?
• It relates to the “One Stream” question, if multiple streams are to be installed, there should be another way.
• What about version upgrade downgrade logic? If developer version is installed, and switch to stable (older) version, is that a downgrade or a forced switch? What about config files, .rpmnew handling etc?
• Ok if there is a clear message
• not required if multiple versions of modules are installable at the same time
• very confusing
• install does not imply replace to me, but that is what is happening!
• Being more explicit could be useful.
• It can overwrite running modules. “dnf module upgrade” or “dnf module switch” are more understandable. Keep current behaviour as it is.
• The user might expect the new stream to be installed in addition to the existing one. I’d prefer an explicit update command, e.g. dnf module update
• Feel there should be a specific “upgrade” or “switch” command. “install” could be aliased to assume an upgrade is desired in the case where an older package is already installed and to prompt the user.
• It should also be possible to do it without installing anything
• I would love if dnf clearly stated that the operation will result into changing streams
• dnf switch-stream would be clearer and less prone to error.
• I think we should have a different delimiter than hyphen to indicate where a name stops and a stream starts. Perhaps a colon?
• The install subcommand makes the admin (me) believe I am going from state => “no files present” to state => “some files present”. There really should be a stream, jump, or switch subcommand.
• i’d like to be able to use multiple streams

How do you like that updates won’t jump to another stream?¶

Anything else about not jumping streams during updates?¶

• Yes. What happens when a stream is EOL, though?
• Would like a notification that a new stream is available, even though it isn’t updated automatically.
• À message about available modules
• would mess the parallel/multiple simultaneous modules versions
• It’s what consumers (i.e. developers) would expect. Cool!!
• Jumping automatically to a potentially incompatible version is certainly not liked. It is like upgrading to next Fedora version automatically with ‘dnf update’. So, how you would NOT jump to the next stream?!
• That fits in line with what I would expect.
• streams shouldn’t be jumped during updates, but streams probably shouldn’t track specific software versions either

Is having pre-defined profiles important to you?¶

Is the ability to install individual packages from any module important to you?¶

Anything else about profiles?¶

• Installing individual packages “from any module” is not important. Ability to install specific individual packages from somewhere is very important.
• This section need a lot of expansion. I still don’t clearly understand how a profile is different from a RPM metapackage.
• Default profile should be lean and stable during the lifecycle. Add complex profiles on top.
• Is there only 1 default profile or multiple choices?
• Define ‘any module’ and it might change a bit - if ‘any module’ means anything in the universe of modules, then it’s not very important. If you define it to mean ‘any module that you have enabled on your system’ then it’s fairly important.
• individual packages from the same stream yes
• not clear on what profiles are… is this supposed to be like whether to include -devel packages or something?

Enabling a module first is required to install a custom set of packages from the module. How do you like this functionality?¶

Anything else aboyut “Enabling a module first is required to install a custom set of packages from the module”?¶

• If a package isn’t available from any enabled module, but is available from one or more non-enabled modules, list those modules so the user can elect to enable one of them. This is like the RHEL repo conundrum (“what repo contains the package I want?)
• I wish dnf to have feature like auto-enabling or suggesting modules
• Not very clear,
• keep the dependancy as light as possible, no bloated requirements
• For backwards compatibility, it should be possible to just install the package, i.e. in its highest version available.
• Packages should have a default module associated. A message stating which module was enabled should be displayed. This will habilitate the new feature to current users in a seamless way
• Having no default is just annoying and just another config step
• Does enable mean that it gets started? What if the system isn’t ready or broken when started even with a default profile?
• Its ok as long as it happens in the background. I would not like being forced to execute 2 commands when I am used executing one.
• seems reasonable.

How do you like the concept of a system profile?¶

Anything else about the concept of a system profile?¶

• I think this is going to be confusing to users. We’ll see how it goes!
• I think it should default to latest release.
• Does this imply that every package is part of a (default) module and stream?
• Use the latest stable by default
• A great way to define a release, I think.
• A default profile shall be provided. Lean and simple.
• I don’t understand the difference between system profiles (where apparently there are defaults?) and modules (where it was stated there are no defaults).
• Not enough info given to be useful to get what concept means
• Not quite sure what this means - is what ‘dnf install httpd’ means different on F27 and F28 (such as those designations are relevant any longer)? For example, at some point does ‘dnf install httpd’ mean to install some future httpd-2.6? Who makes that decision? How is that technically implemented?

Anything else about Modularity?¶

• How are package dependencies tracked/managed across steams, or are they?
• I’m not have good understand about modules’ dependency
• The message and usage is confusing. But do we really need to know the difference between package and module? But what I miss is a dependency graph option
• It’s superb. Just keep the “principle of least annoyance” in mind when making changes.
• I really love it
• Its not explained here how the exclusivity of streams is achieved.
• Are there dependencies between modules? What happens if two different modules need different versions of the same library? Can I break modules by installing rpms of wrong versions? ‘dnf help module’ doesn’t tell you which sub commands can follow ‘module’. Nor does ‘dnf module —help’. Also ‘dnf module install –help’ gives you the general help for ‘dnf module’ instead of specific help for ‘dnf module install’.
• seems like a neat idea. if there’s a clean UI & good integration with the base system (services, etc) it sounds like a useful way to handle this