On 1 August 2017 at 21:32, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
-----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?
The issue I am seeing with this is that people who want to keep existing scripts are also wanting to keep existing package mechanism. If I say yum install httpd I am expecting to get the RPMs and setup I have for N years. I am not expecting to get a profile and modular set of tools decided by someone else who came up with a name httpd which matches a different case need. The same with WordPress or some other toolkit.
If the module WordPress pulls in maria-db and my site has been using PostgreSQL, I am not just going to be confused.. I am going to be angry because my other scripts to seed the database aren't working. The quick answer is "Well write a profile which makes a module you want.." but that isn't what we were striving for... that existing scripts and methods are as similar as possible. Instead we have now forced someone at probably 2 am when a system had to be redeployed for an emergency to learn that they have nonworking scripts.
We keep harping on "surprise is the opposite of engagement" and then we jump down the "surprise!" route every time we want to make a new technology because it seems faster to get people up to speed.
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@lists.fedoraproject.org
Stephen J Smoogen.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
