Re: debconfig-common new template text review
Paul Gevers:
>> The package ${pkg} needs to create new MySQL users, using one of the
>> available authentication plugins. Please specify...
>
> My problem with this sentence is that it's not the creation process of
> the user(s) that needs the plugin. It's the plugin that the MySQL user
> (so, the package) will use when it wants to authenticate to the MySQL
> server.
Ah, right - I was misled by the original description "the MySQL
authentication plugin to be used when creating new users through
dbconfig-common". No, it doesn't use the plugin to create them, it
just sets an attribute of that newly-created user that defines how the
database will expect login attempts to work - is that it?
Will it in fact be the case that "The package ${pkg} needs to create
new MySQL users"? If so then the context we need to give might be
something like
The package ${pkg} needs to create new MySQL users, which can be
configured to use any of the available authentication plugins. Please
specify...
Or if it's only one new MySQL user, we should use the singular. And
if the users already exist then we need to explain it differently.
Oh, wait, this alternative approach works better than I was expecting:
Please specify which of the available plugins the package ${pkg}
should configure database user accounts to use for authentication
with MySQL.
> In some cases, like PHP based packages, the MySQL client library
> isn't supporting all plugins, so the package has to tell the server that
> the user allowed to (and will) connect via a non-default plugin.
"Tell the server" means "set as an attribute of the DB user account",
right?
>> But what actual decision are users being asked to make? If they read
>> the sentence "Please specify whether a particular MySQL authentication
>> plugin should be enforced" and decide that the answer is "no", does
>> that mean MySQL is free to give a different undefined behaviour each
>> time?
>
> Rafael, can you answer this question. I don't know. But I guess this is
> one of the difficult problems with the fact that remote MySQL/MariaDB
> support may mean that we are talking to a different version than we
> would expect in our "own" release. I.e. in a Debian bullseye package we
> may be talking to a Redhat whatever version of MySQL server.
It's impressive that you've got this working at all!
>>> not changing the current selection will work - if ${pkg} doesn't support
>>> the default it should have changed the selection to a working one.
>>> """
>>
>> Unfortunately the current selection might be the one I switched to
>> five minutes ago and now want to switch back from because it doesn't
>> work. Especially if I'm correctly understanding this: if ${pkg}
>> doesn't support the MySQL default (whatever that is), it'll switch to
>> recommending something else, but will let the user select any of the
>> alternatives without giving any indication of which ones it supports?
>
> Unfortunately, that's correct. The package can only change the selection
> during the initial phase where the debconf template is still empty. Once
> it has been changed, there is no way to learn what the original
> selection was.
>
>> Meanwhile, "should have" makes it sound as if we don't trust it; if we
>> *do* trust it maybe we can phrase it more like a guarantee.
>>
>> Leaving the selection set to its default will always work, but other
>> options may not be supported by ${pkg}.
>
> This isn't true, as the default is the MySQL server default.
I thought you said... yes, you definitely said
if ${pkg} doesn't support
the default it should have changed the selection to a working one.
So I don't understand. It isn't helping that there are (at least)
three different layers of "default" behaviour involved:
1) this debconf prompt's current selection;
2) the plugin that this package automatically prefers by default
unless you use this template to select something else;
3) the database's default authentication system;
"Leaving the selection set to its default" is talking about (2)...
Maybe we could avoid the word and say:
Leaving the selection set to its original value will always work,
but other options may not be supported by ${pkg}.
> The problem
> we're trying to fix is for packages that don't support the MySQL
> default. They can change the initial selection, but are powerless if the
> user decides to change it. However, if the current (client side) system
> needs to talk to a remote server, the user may need to explicitly state
> the plugin as both sides may not be aligned on the same MySQL default.
(Even if it isn't possible to get the name of ${pkg}'s preferred
plugin onto the screen here, presumably it could at least be in a
README somewhere?)
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: