While the kdelibs/kspell2/ library always compiles the ispell plugin (also if ispell isn't installed) as it doesn't need any header/library for its compilation, the aspell plugin will be compiled only if aspell is installed as it needs "/usr/include/aspell.h" and "/usr/lib/libaspell.*". For this reason the ebuild line spell? ( || ( app-text/aspell app-text/ispell ) ) isn't right as it choose between them and if ispell is installed, aspell won't be installed. I'll suggest to add another local use flag "aspell" that will esplicity enable the aspell support. In this way the compilation of the aspell plugin is deterministic. DEPEND = aspell? ( app-text/aspell ) RDEPEND = spell? ( app-text/ispell) << As it's not needed at compilation time. Them we should also add the explit configure flags for the compilation like is done in bug #81966. myconf="$myconf $(use_with aspell)" I'll attach the patch that I'll commit upstream. kde herd: any thought?
Created attachment 51329 [details, diff] kdelibs-kspell2-plugins-configure.in.in.patch Needs to be commited upstream.
Two useflags for the same thing seems a bit much, what about adding the patch upstream and then doing something like: if use spell && has_version app-dicts/aspell; then myconf="$myconf --with-aspell" else myconf="$myconf --without-aspell" fi
I'm ok for the fact that 2 use flags are too much but I was doing this for a dependencies problem. My idea was that the user should be aware that it can use both the spell implementations and the fact that if we make your proposed check, portage won't be aware of this dep and so a possible depclean will remove aspell and break libkspell.
Portage can remove the first package of an ||-statement if it's installed?
The latest kdelibs ebuild uses the check in comment #2. This should be enough for now...
