Re: debconfig-common new template text review

Hi Justin,

On 09-08-2019 00:22, Justin B Rye wrote:
> 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?

I think that is the right description, yes.

> 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.

Ack. Although that sentence for me as a non-native speaker is difficult
to parse. I love it that Dutch makes it one word (such that on first
read, my mind doesn't stop three times, but only once for "database user
accounts"). I don't know how to improve that though.

>> 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?

I think so, yes.

>>> 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!

That honor goes to seanius, who long since retired from Debian.

>>> 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.

Ack. I didn't claim my proposal was perfect yet :)

> 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}.

With remote databases the phrase "will always work" is dangerous. It
will work (minus bugs) if the database and the client are on the same
Debian/derivative release. Cross releases isn't possible to guarantee.
So I'd rather claim "should always work" or maybe you can come up with a
smarter (more extensive) disclaimer.

>> 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?)

Yes. Paragraph 1.4.1 of the proposed database policy [1] also mentions
that: "With this in mind, directions for manually installing (and
upgrading if relevant) the database must be included in the
documentation for the package."

Paul

[1] https://www.debian.org/doc/manuals/dbapp-policy/

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAl1RuuoACgkQnFyZ6wW9
dQp6sggAsAXLgt0D1fJAWEaWL4hR0oWK8FJ1uU2HMJWokfdQZLvUXRjA+uLrbDU2
AgubV06IBrFKnb29lRc7xCahrBdbP5ZAPzQh3xmFaEwywmUP6cuBeMiU9iq8J+PU
lB0EsXIvjDnSF+oe8Z+AMi3iasb/aDWD6i1pXm2M6PyyLk5EX1L90kXkFA5UP53m
yb9IDDCjyckWYSputkZ7EjnuRpAOPg8Iavgaw4tKRbIzDPB4oIbD+DoCvuVJHsIs
lxtNNduXsEi2p606ECgJyioqvScB4RE2P/3PVi9z0kcVGtJ4Gd9Rq49VJcOGMymi
ToCad7XJyId9HkY5wzqQJ0oYu5Iq9A==
=iF4J
-----END PGP SIGNATURE-----