-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, Aug 1, 2017 at 6:48 PM Matthew Miller wrote: >On Mon, Jul 31, 2017 at 10:59:58AM -0400, Matthew Miller wrote: >> The thing that jumps out immediately is that respondents _really_ >> prefer the "dnf module install httpd" syntax — 73% love or like that, >> while 7% dislike or hate it. 21% love or like "dnf install httpd" for installing >> modules, while 46% dislike or hate it. And a full half of that dislike >> is hate, or in other words more people completely hate it than like or >> love it _combined_. The "dnf install @httpd" syntax gets just a little .> bit less hate, but also less love. > I talked to Langdon, who is a strong advocate of the "bare" `dnf > install httpd` syntax. > His argument is that modules should be seen as if they are > metapackages¹, and that it would be an odd extra step to have to > effectively first enable the ability to install packages and _then_ > install them. I'll let Langdon make his own argument, but basically > akin to shipping Fedora split in different repos, some of them > disabled. That's because with the other options, if you install Modular > Fedora and don't have an enabled module containing the package you ask > for, you get "that doesn't exist".² I'm going to step up and argue in favor of the bare `dnf install httpd` syntax. I think it makes a lot of sense to keep existing scripts and methods of operation as similar as possible (look at how much chaos followed the yum->dnf rename). If nothing else, we should be striving to reduce the impact on existing users to as little as possible. We're looking to get to a world where *everything* is in a module of some kind. In this world, does it really make any sense from a user perspective to care how the software is partitioned under the hood? My view is that the action of `dnf install httpd` should essentially be (under the hood): * Look up which modules provide the 'httpd' package * Check the metadata for which is the "default" module stream for this installation * Enable the default module stream. * Install the default profile from that module. We then reserve the `dnf module` command for anyone who is attempting to install a module or stream that is non-default. The benefit to this approach is that users who are used to the way Fedora operates today will get *exactly the same behavior*, except that additional metadata and options are available if they realize they need or want to be on another stream of particular software. Furthermore, existing tools that interact with the DNF CLI will be able to invoke it with exactly the same commands and get the same output (well, a proper superset, anyway). -----BEGIN PGP SIGNATURE----- Version: Mailvelope v1.8.0 Comment: https://www.mailvelope.com wkYEAREIABAFAlmBK7oJEHolVWI2uqOjAAB9kQCgkxDrVpujdzIYutJv+19u q1g4lG8AoJVRHt1YBWtntLDD+PCLH8pSCi8A =llkB -----END PGP SIGNATURE-----
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
