Hi Justin,
On 07-08-2019 23:56, Justin B Rye wrote:
> Paul Gevers:
>> The problem with "this allows different packages to choose for
>> themselves" is that one shouldn't choose "unspecified/default", but one
>> should rather not change the selection. Because a package can have
>> changed the default from unspecified to one of the other settings.
>>
>> Also I don't think how the plugin is used is crisp and clear.
>
> I can't make it any clearer than my own understanding of what this
> debconf template is all about.
So, that is exactly what I try to improve here, your understanding and
that of everybody involved, including the future reader of the template.
The fact that it isn't clear for you yet, is exactly confirming my worries.
>> So, how about (I'm not 100% happy yet):
>> """
>> Please specify whether a particular MySQL authentication plugin should
>> be enforced for the new users created by ${pkg} . Most of the time,
>
> It might make the phrasing easier if we start by giving some sort of
> brief context, like:
>
> 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. 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.
> 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.
>> 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. 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.
>> Also, I think Justin fully understood the meaning of
>> default/unspecified.
>
> Missing negation?
No, merely a "doesn't" missing. I didn't mean "misunderstood".
Paul
Attachment:
signature.asc
Description: OpenPGP digital signature