Re: Help wanted for template improvements [Bug#805455]
Paul Gevers wrote:
> Control: tags -1 help
>
> Dear Debian-l10n-english people, dear Dan,
>
> 積丹尼 Dan Jacobson wrote:
[...]
>> User is used to doing
>> $BROWSER http://localhost/phpmyadmin/
>> and seeing all his databases.
>>
>> So upon
>> # aptitude purge phpmyadmin
>> user sees
>>
>> Template: dbconfig-common/dbconfig-remove
>> Type: boolean
>> Default: true
>> Description: Deconfigure database for ${pkg} with dbconfig-common?
Notice the "database for ${pkg}", which seems reasonably clear to me;
would saying "${pkg} database" be better or worse?
Apparently you're worrying that it might be threatening to remove
mysql without taking into account any other packages you have
installed that directly depend on it. That would be an obviously
catastrophic thing to do... and also pointless. If mysql no longer
had any reason to be installed, the package management system would
routinely notice that and suggest getting rid of it all on its own,
without any need for phpmyadmin to use the nuclear option!
Besides, if it purged the whole DBMS, wouldn't that make it difficult
and/or pointless to subsequently de-privilege the phpmyadmin db-user?
[...]
>> and the even more scary:
>>
>> Template: dbconfig-common/purge
>> Type: boolean
>> Default: false
>> Description: Purge the database for ${pkg}?
[...]
>>
>> Whereupon user has a 1/10 suspicion that this just might mean sweeping
>> away all his MySQL databases in addition to just the phpmyadmin MySQL
>> database...
>>
>> So maybe clarify via a listing right there, of what goes, and what
>> stays, so he can scroll through it to get a better grasp of what is
>> about to happen.
>
> I acknowledge that if you are suspicious (and maybe also not a native
> English reader) the text may not be perfect, although we already tried
> hard in the past to make the text as clear as possible. I feel I can't
> do better than we already did without making the text much longer than
> it already is. (I don't think that making it longer is going to help).
Part of the problem is that by the time you get to the end you've
forgotten the straightforward short description, so if anything it's
already too long.
> Also, I don't think that creating a list is appropriate as not all
> database types support it and there is only one database that is going
> to be removed, the one associated with the package. Apart from that,
> dbconfig-common has no knowledge of what is going to happen in the
> maintainer scripts that it executes on behalf of the package.
>
> So, if anybody has a good idea on how to improve the text, I am open for
> it. However, I am not myself going to propose new text.
>
All this would be so much easier if we didn't casually use the same
word "database" to refer to so many different things, from an .sql
file to a brand of DBMS to a physical server.
Since in this text we only ever mean "bunch of tables", would it do
any good to substitute some word like "dataset" at the crucial point?
(In fact I see it already does carefully say "data" in several
places.)
And maybe we should also avoid the word "purge". Yes, we're purging a
package, but we're not purging a database, we're removing database
files (whether via "rm" or "sql drop table...").
So, Dan, would any of the following nitpicks improve the text?
Description: Deconfigure database for ${pkg} with dbconfig-common?
Since you are removing ${pkg}, it's possible that you no longer
want the underlying database and the privileges for the user
# ^insert "files"?
associated with this package.
.
Please choose whether database removal and privilege revocation should be
handled with dbconfig-common.
.
If you choose this option, dbconfig-common will check if ${pkg} provided
scripts and database commands to undo package specific operations and run
them if they exist. Then it will ask if you want to purge the database and
# remove
revoke the standard privileges for the user of ${pkg}. If you don't want
any of this, or if you want to handle this manually, you should refuse
this option.
Description: Purge the database for ${pkg}?
# Remove
If you no longer need the database for ${pkg} and the privileges of
# ^insert "files"?
the database user of ${pkg}, you can choose to remove the database and
revoke the privileges now.
.
If you no longer have need of the data being stored by ${pkg}, you
should choose this option. If you want to keep this data,
or if you would rather handle this process manually, you should
refuse this option.
> Paul
> By the way, help with rephrasing other parts of the dbconfig-common
> templates to solve bug 802941¹ is also more than welcome.
>
> ¹ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802941
Dan's summary being:
>> In fact you don't even need to parse the messages...
>> Just somehow mention better that Retry is what one wants if the server
>> needs to be started first.
No, "retry" - or maybe it should be "retry (skip questions)" - is what
one wants *after* one has identified the problem and implemented a
solution, regardless of the nature of that problem and solution.
It seems to me that adding a catalogue of possible problem sources
would only distract users from looking at the actual error message.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: