Hi all,
On 19-11-15 23:33, Justin B Rye wrote:
> Notice the "database for ${pkg}", which seems reasonably clear to me;
> would saying "${pkg} database" be better or worse?
No idea, but also, if it is, is it so much better that it is worth
changing the template for this?
> 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?
I agree with your reasoning, but maybe the admin has little knowledge
about how DBMS work.
> 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.
Fully agree.
> 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?
Only if that word is recognized, which I seriously doubt.
> And maybe we should also avoid the word "purge".
This may be a good idea. I must admit that I, as a non-native speaker,
don't have a clear feeling of the difference between remove and purge,
except that I know the difference from the behavior of apt. I know you
can purge hoses and volumes with gas.
> 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...").
I am not sure if all DBMS really use files per database. Does anybody
know? I think it may just add to the confusion if we do that.
>> ¹ 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)"
Indeed, "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.
Exactly my idea. The only thing I could come up with is to say something
like "E.g. in case you forgot to start your database." But there may be
more common examples that would be better, e.g. network problems, if we
go that route.
On 20-11-15 11:10, Justin B Rye wrote:
> maybe we should just close this bugreport, because
> this potential misunderstanding isn't likely enough to be worth adding
> a whole extra paragraph. Lengthening the explanation will just lead
> to people reading less of it.
I feel the same, with the emphasis on "worth adding a .. paragraph" (for
translators and for readers that read less because of TL;DR).
Paul
Attachment:
signature.asc
Description: OpenPGP digital signature