Bug 37092 - Red Hat 7.1 randomly changed aspell to use some foriegn language
Summary: Red Hat 7.1 randomly changed aspell to use some foriegn language
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: aspell
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-04-22 19:26 UTC by David Woodhouse
Modified: 2008-08-01 16:22 UTC (History)
0 users

Clone Of:
Last Closed: 2001-04-23 14:39:14 UTC

Attachments (Terms of Use)

Description David Woodhouse 2001-04-22 19:26:06 UTC
Before installing Red Hat 7.1, my machine was correctly set up for the
British language (en_GB). After the upgrade, the spelling checker was
broken - it appears to have installed en_US dictionaries. No other random
unwanted languages, just en_US.

Attempting to remove the offending package failed:
imladris /usr/lib/aspell # rpm -e `rpm -qf american-lrg.multi`
error: removing these packages would break dependencies:
	aspell is needed by aspell-en-gb-0.32.6-2
	aspell is needed by gaim-0.11.0pre4-2
	aspell is needed by xfig-3.2.3c-8

What is the correct way for me to fix this? Evidently I did it the wrong
way last time - probably just by manually removing the files which were
erroneously included in the program RPM and fixing the symlinks.

Comment 1 Trond Eivind Glomsrxd 2001-04-23 14:30:14 UTC
The US dictionaries are part of the aspell package, so you can't remove them.
Not a bug.

Comment 2 David Woodhouse 2001-04-23 14:39:09 UTC
IMHO the fact that the en_US dictionaries cannot be removed _is_ a bug. But it's
the less important of the two problems I reported.

The fact that it _changed_ to use en_US dictionaries again when my previous 7.0
installation was correctly set up for my own language is more important problem.

Either there's a way to set aspell up correctly such that upgrades don't revert
to incorrect behaviour, or there's a bug in the package.

If the former is the case, please assist me in my ignorance and tell me what I
should do to make it work (and possibly refile this bug against the installer,
which I'm _sure_ was told my preferred language).

Comment 3 Trond Eivind Glomsrxd 2001-04-23 14:52:07 UTC
It shouldn't change the default language, as that is set in your own
.aspell.conf - just add a line "lang british" there.

As for the US dictionary present there, it's there as the default language if
none are specified and would cause too many errors if absent.

Comment 4 David Woodhouse 2001-04-23 15:04:40 UTC
A system-wide fix is required. /etc/aspell.conf doesn't seem to work, but would
be an acceptable solution.

Having the en_US dictionary isn't the end of the world for systems with disc
space to waste, I suppose - but wouldn't it be possible to put the dictionary
into a separate RPM and give aspell a dependency which can be satisfied by _any_

Post-install: [ -r /usr/lib/aspell/default.multi ] || ln -sf whatever.multi

Or have an empty 'default.multi' file installed as part of the program RPM.

Comment 5 Trond Eivind Glomsrxd 2001-04-23 15:07:38 UTC
Try /usr/etc instead of /etc ("aspell dump config" should show you the

And no, aspell looks for the US one by default - removing it would confuse it
rather well.

Comment 6 David Woodhouse 2001-04-23 15:26:30 UTC
Aha. Thanks, that works. An installer bug then? :)

Comment 7 Trond Eivind Glomsrxd 2001-04-23 15:35:39 UTC
It will become less of an issue in the future, as aspell is going to try using
the locale for determining dictionaries. Unfortunately, it doesn't build very
well because of dependance on a very bleeding-edge version of libtool.

Comment 8 David Woodhouse 2001-04-23 15:41:00 UTC
That will be useful. Would it be possible to fix the dependency on
'english.multi' at the same time? Perhaps this is a suggestion I should make to
the upstream maintainers.

If done properly, it could be entirely compatible with old installations.

(if there's a configured language, use it. else, if there's a default.multi, use
it. else, if there's an english.multi, use it.)

Note You need to log in before you can comment on or make changes to this bug.