[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debconfig-common new template text review



Paul Gevers:
> Sorry to say, but I am still not extremely happy with the current
> wording, because I don't think it reflects what's really happening. I'm
> finally having time to think about it myself.
> 
> Are all debconf front-ends guaranteed to show the existing selection?

Given that one of them is "noninteractive", no; but the dialog
frontend does.

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

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?

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

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

> Also, I think Justin fully understood the meaning of
> default/unspecified.

Missing negation?

> And the other templates don't have a colon, so
> let's stick with a dash:
> """
>   * unspecified - use the default determined by the MySQL server
> """

Yes, that looks like d-l-e House Style!
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package


Reply to: