On Sun, Jul 06, 2014 at 12:18:51PM +0100, Justin B Rye wrote:
> Christian PERRIER wrote:
> > Template: dictionaries-common/debconf_database_corruption
> > Type: error
> > #flag:translate!:3
> > Description: Possible debconf database corruption
>
> This is a case where we probably do need to let debconf talk about
> debconf, but I can't believe we need to go this far into the
> implementation details.
For debconf is sometimes hard to know if a missing template is due or not to
database corruption, unless all templates are reloaded. Since ispell
dictionaries and wordlists provide additional info about the untranslated
possible values of the debconf question, this can be noticed and warned
about.
> > The configuration question for "${question}" is empty but some
> > elements are installed for the "${class}" class:
>
> What does it mean for a question to be empty? And what on earth is
> all this about elements and classes? Is this perhaps saying:
>
> There is no answer on file for the configuration question
> "${question}", but some elements are installed for the "${class}"
> package class:
This can mean that question value is "" or that question is lost, usually
because of debconf database corruption.
> (And "${class}" is either "wordlist" or "spelling dictionary", the
> difference being that spelling dictionaries are annotated to
> distinguish inflectional affixes?)
>
> > .
> > Choices_dictcom: "${installed_elements}"
> > Choices_debconf: "${choices_value}"
> > Owners/error: "${shared_owners}"
>
> What do these list item names mean? The terms are meaningless to
> users (you can't expect them to be familiar with the abbreviation
> "dictcom") and not detectably used elsewhere in the package.
>
> The introductory text had me expecting this to be a three-item list of
> installed "elements", whatever those are exactly, but apparently the
> first list item contains that. So what are the second and third list
> items? Why is there a value for "Choices_debconf" if the debconf
> question is "empty"? And what on earth is an "owners/error"?
>
> This needs a complete rewrite, using human-readable (and translatable)
> labels; my guess is
>
> .
> Installed elements: "${installed_elements}"
> Debconf setting: "${choices_value}"
> Involved packages: "${shared_owners}"
They are intended for possible bug reports, but I am also not happy with
their current status. Some (long) explanation follows.
dictionaries-common uses a rather complex system to deal with the main
shared question. To make translation easier, it uses a normal question under
dictionaries-common control. All ispell dictionaries and wordlists provide a
shared shared/packages-{ispell,wordlist} template, and am additional
${package}/languages template whose default value provides the language(s)
keys provided by the package (things like "castellano8 (Spanish 8 bit)").
This way, template translation for the selection menu is handled in a
single location at the cost of much higher complexity.
debconf database corruption can be caused by the main template being lost,
with or without the shared question being also lost.
"Choices_debconf" or "Debconf setting" stands for the possible choices
debconf shows. If this problem happen it will most likely be only "Manual
symlink setting".
"Choices_dictcom" or "Installed elements" stands for the possible values that
should have been made available to debconf (except "Manual symlink setting").
"Owners/error" should show the list of owners for the
shared/packages-ispell or shared/packages-wordlist question, or the error
message returned by debconf in case of error.
May be something like
Available values: "${installed_elements}"
Involved packages/Error: "${shared_owners}"
is enough.
> > This can be related to a corruption of the "debconf" database.
> > See "/usr/share/doc/dictionaries-common/README.problems", section
> > "Debconf database corruption".
>
> Slightly wobbly English.
>
> This may be due to corruption in the debconf database. See
> "/usr/share/doc/dictionaries-common/README.problems" on "Debconf
> database corruption".
Yes, this sounds better
> > In this case, running "/usr/share/debconf/fix_db.pl" can help to put
> > the debconf database in a consistent state.
>
> Given that they probably shouldn't run fix_db.pl as root without first
> reading the README, why not just let the README tell them about that
> solution? Perhaps (not in my patch) it should be:
>
> database corruption" and what to do about it.
That info is already there. I added this tired of people that after being
pointed to "/usr/share/doc/dictionaries-common/README.problems" by previous
error message were still asking what to do (making me think that they did
not read it). I agree this is not ideal.
> Meanwhile, what happened to the alternative diagnoses that used to be
> mentioned in dictionaries-common/invalid_debconf_value ("This can also
> be caused by problems during installation of packages [...] This error
> message can also appear during ispell dictionary or wordlist
> renaming")?
No problem, they are below. I initially merged both templates, but later
changed my mind to split them into more specific templates. This is more
clear and avoids too large templates.
> > Some questions are likely to be asked after this message in order to
> > try leaving the dictionaries system in a (provisionally) working state.
>
> "Try leaving" doesn't quite work, so tweak it to match the version
> elsewhere:
>
> Some questions are likely to be asked after this message in order to
> leave the dictionaries system in a (provisionally) working state.
Agreed too.
> > dictionaries-common. "${value}" does not correspond to any installed
> > package
> I wish somebody would translate "$value" for me. What *kind* of value
> is this variable going to expand to? Is it something like "wfrench"
Is something like "castellano8 (Spanish 8 bit)". It is both the language
unique identifer and the language name, preferrably 7 bit and should not
change. We initially used a poor's man internationalization like that
(this system is more than 10 years old). Since debconf later allowed
C-Choices, an additional new translatable ${package}/elanguages was added.
> > That is usually caused by problems at some time during packages
> > installation, where the package providing "${value}" was selected for
> > installation but finally not installed because of errors in other
> > packages.
>
> This is usually caused by previous problems during package
> installation, [...]
Agreed
> > To fix this error, reinstall (or install) the package that provides
> > the invalid value. Then, if you don't want this package on
> > your system, remove it, which will also remove its configuration
> > settings in the "debconf" database. A choices menu
> > will be shown after this message in order to leave the system in a
> > working state until you fix the problem.
>
> I think we should use the value of "${value}" instead of the rotten
> variable-name that users don't know about. Alternatively you could
> say "the invalid default dictionary setting", but then the user still
> needs to puzzle out what it means for a package to provide that; it's
> much easier to guess what package provides wfrench!
>
> Also, there's no need in this case to explicitly mention debconf.
>
> To fix this error, reinstall (or install) the package that provides
> "${value}". Then, if you don't want that package on this system,
> remove it, which will also delete this configuration setting. A menu
> of choices will be shown after this message in order to leave the
> system in a working state until you fix the problem.
I did not put "${value}" here because is not a single word and could be a
bit repetitive, but I do not have problems adding it, just remember that is
not the package name.
> > This error message can also appear during ispell dictionary or wordlist
> > renaming (e.g., wenglish -> wamerican). In this case it is harmless and
> > everything will be fixed after you select your default in the menu(s)
> > shown after this message.
> >
> > Template: dictionaries-common/default-ispell
> > Type: select
> > Choices-C: ${choices}, Manual symlink setting
> > __Choices: ${echoices}, Manual symlink setting
>
> I gather this isn't a typo, and that e-choices are connected to
> e-languages, whatever those are...
Not a typo, "${echoices}" is the possibly translated string, after
elanguages..
> > Template: dictionaries-common/move_old_usr_dict
> > Template: dictionaries-common/remove_old_usr_dict_link deletes
Thanks for reminding me about these. They are obsolete and indeed not used.
Can safely be removed (I also have to remove a bogus call in config)
> > Template: dictionaries-common/old_wordlist_link
> > Type: boolean
> > Default: true
> > _Description: Remove obsolete /etc/dictionary link?
> > There is a /etc/dictionary link on the system. This is obsolete and no
> > longer means anything. This link should be removed.
>
> This system has an obsolete symlink "/etc/dictionary". This is no
> longer meaningful, and should be removed.
Agreed, although I doubt that this ancient template is any longer meaningful.
> > You will be asked to explicitly select the default wordlist during
> > installation of wordlist packages. You can change your selection at any
> > time by running "select-default-wordlist".
> >
> > Template: dictionaries-common/ispell-autobuildhash-message
> > Type: note
>
> Surely reporting an error is a job for "Type: error"?
Yes, better.
> > #flag:translate!:3
> > _Description: Problems rebuilding an ${xxpell} hash file (${hashfile})
>
> "xxpell" looks even more like a typo than echo-ices, but apparently
> that's the variable name the scripts expect...
>
> > The following error happened:
> > .
> > ${errormsg}
> > .
> > This error was caused by a package providing "${hashfile}", although it
> > can be made evident during other package postinst. Please report
> > a bug against the package providing "${hashfile}".
>
> Users shouldn't need to know about {pre,post}{inst,rm} scripts.
>
> This error was caused by a package providing "${hashfile}", although it
> may be triggered by another package's installation. Please submit a bug
> for the package providing "${hashfile}".
Agreed,
> > Template: dictionaries-common/remove_old_usr_dict_link
As wrote above, is obsolete, no need to worry about it.
> > Template: dictionaries-common/selecting_ispell_wordlist_default
>
> Looks okay.
>
> Meanwhile in the control file:
>
> > Package: dictionaries-common
> [...]
> > Description: Common utilities for spelling dictionary tools
> > These are utilities shared by all ispell, myspell and wordlist
> > dictionaries, including support for some tools that use them
> > (like emacsen, jed and mutt) and some patched spell-checking
> > lisp files for better system integration.
>
> This has some trivial "house style compliance" bugs, mostly in
> capitalisation. It's also just a bit hard to follow.
> I would suggest:
>
> Description: spelling dictionaries - common utilities
> This package provides utilities shared between all wordlists and spelling
> dictionaries for Ispell, Aspell, or MySpell/Hunspell. It also includes
> support infrastructure for software using them (such as JED and Mutt),
> and some patched spell-checking Lisp files for better Emacs integration.
Looks better.
> > More info about naming conventions and availability of those
> > dictionaries in the README.Debian file.
>
> This is trying to be a separate paragraph, but doesn't even manage to
> form a sentence.
Seems something went lost when adjusting lines ;-).
> More information about the availability of these dictionaries and their
> naming conventions is available in the README.Debian file.
Reads much better,
> > Package: dictionaries-common-dev
> [...]
> > Description: Developer tools and Policy for spelling dictionary tools
> > Full text of the Debian Spelling Dictionaries and Tools Policy and
> > some debhelper like helpers.
> > .
> > Only of interest for developers maintaining wordlists or dictionaries
> > for ispell, aspell or myspell/hunspell.
>
> Description: spelling dictionaries - developer files
> This package provides the full text of the Debian Spelling Dictionaries
> and Tools Policy, and some debhelper-like helpers.
> .
> It is only of interest for developers maintaining wordlists or
> dictionaries for Ispell, Aspell, or MySpell/Hunspell.
Better,
> --
> JBR with qualifications in linguistics, experience as a Debian
> sysadmin, and probably no clue about this particular package
Thanks a lot for your really extensive review. It was indeed very helpful.
Will wait a bit more and prepare a new diff.
Regards,
--
Agustin
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
