Bug 37092 - Red Hat 7.1 randomly changed aspell to use some foriegn language
Red Hat 7.1 randomly changed aspell to use some foriegn language
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: aspell (Show other bugs)
7.1
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-04-22 15:26 EDT by David Woodhouse
Modified: 2008-08-01 12:22 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-23 10:39:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2001-04-22 15:26:06 EDT
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 10:30:14 EDT
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 10:39:09 EDT
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 10:52:07 EDT
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 11:04:40 EDT
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_
dictionary?

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

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


Comment 5 Trond Eivind Glomsrxd 2001-04-23 11:07:38 EDT
Try /usr/etc instead of /etc ("aspell dump config" should show you the
configuration).

And no, aspell looks for the US one by default - removing it would confuse it
rather well.
Comment 6 David Woodhouse 2001-04-23 11:26:30 EDT
Aha. Thanks, that works. An installer bug then? :)
Comment 7 Trond Eivind Glomsrxd 2001-04-23 11:35:39 EDT
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 11:41:00 EDT
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.