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.
Created attachment 111972 [details, diff] Patch to aspell-0.60.5.ebuild Note that {R,}DEPEND shouldn't contain virtual/aspell-dict to avoid circular dependencies.
Thanks, in CVS now.
(In reply to comment #12) > Thanks, in CVS now. > Are you sure? http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-text/aspell/ http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-text/aspell/aspell-0.60.5.ebuild?rev=1.100&view=log
Whoops - I am now :) Sorry about that; doing too many things at once...
