Bug 48072 - aspell needs a dict, but there is no dependency - leads to a depclean inconsistency
|
Bug#:
48072
|
Product: Gentoo Linux
|
Version: 2004.0
|
Platform: All
|
|
OS/Version: All
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: app-dicts@gentoo.org
|
Reported By: mike@nerone.org
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: aspell needs a dict, but there is no dependency - leads to a depclean inconsistency
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2004-04-16 14:24 0000
|
I would like to suggest that a dependency be added so that aspell requires
virtual/aspell-dict (a default of aspell-en seems reasonable). This would
accomplish two things: first, it would simply help people who don't know they
need to install one (e.g. if they missed the message when aspell was being
emerged as dependency).
The second benefit is more important. Consider this situation:
1. User emerges a package that depends on aspell - suppose app-text/enchant
(also suppose that this remains the only app on his system that wants aspell).
2. User emerges aspell-en, for example.
3. User later decides he doesn't want enchant anymore, and unmerges it.
4. User then does an "emerge depclean" to remove unneeded packages.
Because aspell-en is in the world file, and it depends on aspell, the depclean
will not unmerge aspell and aspell-en even though they are no longer needed.
First thought on how to fix this was to do a oneshot emerge on aspell-en in
step 2. The problem with that is that any depclean (even while enchant is still
installed) will want to remove aspell-en, because nothing depends on it and
it's not in the world file.
So if the dict is in the world file, you've got the first problem. If not, and
nothing has a dependency on it, then you've got the second problem. Ideally,
you could have the dict not be in the world file, but a dependency holds it on
the system, so that when nothing requires aspell, aspell and any dicts which we
installed as dependencies or oneshot will be unmerged by depclean. Adding the
virtual/aspell-dict dependency to aspell does that (and is a lot cleaner than
adding the virtual/aspell-dict dependency to all ebuilds which need aspell). It
also doesn't impede anybody's ability to put a dict in the world file if they
wish, thereby gauranteeing that it will remain updated. Personally, I regularly
check --deep, so I don't care about that. It should be our option.
Looks like a forgotten or ignored bug.
Anyway, the idea of installing a dictionary, while installing aspell is fine.
But, I would suggest a mechanism like in kde-base/kde-i18n. Which means,
watching the LINGUAS variable for reasonable things and setting another
variable for dependencies. PDEPEND seams to be the best one for aspell and
dictionaries. Because, aspell doesn't need them for compiling nor for running
(but, it's really useless without one).
If you don't get what I mean, think about adding this to an aspell ebuild:
---8<---
LANGS="af be bg br ca cs cy da de el en eo es et fi fo fr ga gl he hr is it nl
no pl pt ro ru sk sl sr sv uk vi"
for X in ${LANGS} ; do
PDEPEND="${PDEPEND} linguas_${X}? ( app-dicts/aspell-${X} )"
IUSE="${IUSE} linguas_${X}"
done
--->8---
It doesn't work well, i.e. for things like en_GB there should be a mapping,
but I think it would be really helpfull.
(This is the first additional commit after more than 2 years. ;)
And I would change the version and set the severity to enhancement.)
I don't think we should do any of the proposals.
1) Always installing the English dictionary is not a good idea; many people
only have their native language dictionaries installed. Creating a dependency
between the tools and a dictionary is just wrong.
2) Dictionaries are often used by more than one application, and it's not
always necessary to have the "natural" parent application (aspell in this case)
installed in order to use the dictionaries.
With that in mind, I think it's best to keep the language dictionaries
independent. If that's the case, then there's no depclean issue as users will
have had to install the dictionaries directly, so should expect to remove them
directly if they no longer want them.
I certainly see benefits to Daniel's idea (LINGUAS, or at least my notice of
it, came around after I posted this bug). But, I'll address Kevin's points
(mostly) from the point of view of my original suggestions, simply having a
virtual/aspell-dict:
1. (In reply to comment #2)
> 1) Always installing the English dictionary is not a good idea; many people
> only have their native language dictionaries installed. Creating a dependency
> between the tools and a dictionary is just wrong.
English is just a default (much like sun-jdk is the default for virtual/jdk,
but ibm-jdk and jrockit-jdk will satisfy it, as well). If the user installs an
alternate dictionary, aspell-en won't be required. I do see your point about
how defaulting to en might be seen by some in a negative way, though. Daniel's
idea for consulting LINGUAS (or perhaps locale output) addresses that.
> 2) Dictionaries are often used by more than one application, and it's not
> always necessary to have the "natural" parent application (aspell in this case)
> installed in order to use the dictionaries.
I never suggested that the dict packages should depend on aspell. aspell
requires a dictionary (for usefulness), not the other way around. A dict can be
installed without the parent aspell package.
*** Bug 140629 has been marked as a duplicate of this bug. ***
*** Bug 156465 has been marked as a duplicate of this bug. ***
Unfortunately, we cannot have aspell depend on any of the languages, as the
languages depend on aspell for installation (aspell provides the utilities
needed to unpack the dictionaries). This would create a circular dependency,
which we simply can't have.
Ummm...isn't that what PDEPEND is for?
(note: reopening bug to make sure this comment gets noticed - close again if
you must)
You're right - 'twas rather late ;)
I'll look into the LINGUAS thing - did something along those lines recently for
acrobat-reader, so should be able to do a similar thing.
ok; here we go :) I've put 0.60.4-r2 into CVS with the PDEPEND setup so that
it'll install all matching languages listed in LINGUAS. It's masked for the
moment - please unmask in /etc/portage/packages.unmask, try it out and report
back.
Regarding the en vs. en_GB etc issue - since the dictionaries themselves are
the generic language, installing all variations, the PDEPEND only looks at the
parent language codes.
For example, if LINGUAS="en_GB de", you'll only get the German dictionary - set
LINGUAS="en_GB en de" to get both English and German. One reason is that I
think it would be misleading to support the sub-codes. Supporting
LINGUAS="en_GB" would imply only the GB English would be installed, not the US
or CA variants - which is not the case. For the moment at least I don't think
it's worth the extra complexity.
(In reply to comment #9)
> ok; here we go :) I've put 0.60.4-r2 into CVS with the PDEPEND setup so that
> it'll install all matching languages listed in LINGUAS. It's masked for the
> moment - please unmask in /etc/portage/packages.unmask, try it out and report
> back.
I tried modified aspell-0.60.5 ebuild and it works correctly.
Whoops - I am now :) Sorry about that; doing too many things at once...
