You added hspell as dependency to kdelibs, weird, incorrectly and broke the tree - !< should be >= 1.0 - there's a spell umbrella use flag, you should have noticed - you've added it as compile time only (I doubt it's statcally included, but I might be wrong) - you've not added the relevant configure stuff - to recap that: adding use flags without using (or having) proper configure flags is not accetable, sinc it leads to non-deterministic build behaviour - did you ask anyone of the KDE team before doing so at all? - only a small subset of the architectures which have kdelibs keyworded have hspell keyword In short: That was bullshit, revert please.
In the future; please file a bug with a useful summary.
(In reply to comment #0) > - !< should be >= 1.0 I want to block older versions because they block compile > - there's a spell umbrella use flag, you should have noticed there is no hspell useflag and hspell!=spell > - you've added it as compile time only (I doubt it's statcally included, but I > might be wrong) I have not added it as a depend, but as a blocker. > - you've not added the relevant configure stuff - to recap that: adding use > flags without using (or having) proper configure flags is not accetable, sinc > it leads to non-deterministic build behaviour I did not add the use flag, but you are probably right here, we need a hspell useflag. > - did you ask anyone of the KDE team before doing so at all? I am on the kde team, but if you do not like it you are of course free to revert it. > - only a small subset of the architectures which have kdelibs keyworded have > hspell keyword we can only do the proper usefalagging and depending and dropping the unsupported keywords in a new revision, when do you plan to push that out? Can we please get that in then?
The sensible way to do this is: ... IUSE="acl alsa arts cups doc hspell jpeg2k kerberos legacyssl noutempter openexr spell ssl tiff zeroconf kernel_linux fam" ... DEPEND="${RDEPEND} doc? ( app-doc/doxygen ) sys-devel/gettext dev-util/pkgconfig hspell? (>=app-text/hspell-1.0)" ... myconf="--with-distribution=Gentoo $(use_enable fam libfam) $(use_enable kernel_linux dnotify) --with-libart --with-libidn $(use_with acl) $(use_with ssl) $(use_with alsa) $(use_with arts) $(use_with kerberos gssapi) $(use_with tiff) $(use_with jpeg2k jasper) $(use_with openexr) $(use_enable cups) $(use_enable zeroconf dnssd) $(use_with hspell)" and obviously add hspell to use.local.desc. Using the automatic configure to detect the presence of hspell is wrong, as it means the build depends too much on the configuration of the host system. Think about building binpkgs for delivery to other machines. For the same reason I reckon the aspell dependency should be managed the same way I've proposed for hspell above; i.e. IUSE+=aspell, $(use_with aspell).
(In reply to comment #2) > there is no hspell useflag and hspell!=spell As you see, when looking at the ebuild, we use a single spell use flag, chosing the most sensiblbe default - in this case obviously some linguas_he? magic is needed. > > - you've added it as compile time only (I doubt it's statcally included, but > > might be wrong) > I have not added it as a depend, but as a blocker. So you you don't care for correct dependencies!? > > - you've not added the relevant configure stuff - to recap that: adding use > > flags without using (or having) proper configure flags is not accetable, sinc > > it leads to non-deterministic build behaviour > I did not add the use flag, but you are probably right here, we need a hspell > useflag. No. > > - did you ask anyone of the KDE team before doing so at all? > I am on the kde team, but if you do not like it you are of course free to > revert it. You never asked to join the KDE team, getting the emails through the alias doesn't make you a member of any team. The current project page is just incorrect. > > - only a small subset of the architectures which have kdelibs keyworded have > > hspell keyword > we can only do the proper usefalagging and depending and dropping the > unsupported keywords in a new revision, when do you plan to push that out? Can > we please get that in then? Uh, it's your job to file a bug and get hspell keyworded on all architectures before filing a bug asking the KDE team to add hspell to the ebuild. I can't imagine that you still haven't reverted your changes. You broke the tree. Fix that!
(In reply to comment #4) > I can't imagine that you still haven't reverted your changes. You broke the > tree. Fix that! Nonsense... There's no dependency tree borkage as there's no dependency, there's a blocker. Chill out a bit, I guess.
I've removed the pointless blocker for now.
(In reply to comment #6) > I've removed the pointless blocker for now. Well, this is wrong, see Bug 114161. The blocker needs to stay there or you need to hard-disable hspell again, until this gets fixed properly. It won't compile w/ anything <1.0
(In reply to comment #3) actually: > hspell? (>=app-text/hspell-1.0) should be on the initial RDEPEND, of course.
(In reply to comment #8) > (In reply to comment #3) > > actually: > > hspell? (>=app-text/hspell-1.0) > > should be on the initial RDEPEND, of course. As long as hspell is not keyworded (or use masked, if it doesn't work) by all architectures, definitely not. Jakub: *sigh", readded --without-hspell
Isn't there problem with aspell as well? Looking at the ebuild, following scenario seems possible to me: - user has aspell installed, kdelibs build --with-aspell - user installs ispell and uninstalls aspell, spell? ( ) dep is satisfied, but kdelibs are build against nonexisting package
(In reply to comment #10) > Isn't there problem with aspell as well? Looking at the ebuild, following > scenario seems possible to me: > - user has aspell installed, kdelibs build --with-aspell > - user installs ispell and uninstalls aspell, spell? ( ) dep is satisfied, but > kdelibs are build against nonexisting package > So when you switch spelling backends you would expect kdelibs to be rebuilt? This cannot be automated at present.
(In reply to comment #10) > Isn't there problem with aspell as well? Looking at the ebuild, following > scenario seems possible to me: > - user has aspell installed, kdelibs build --with-aspell > - user installs ispell and uninstalls aspell, spell? ( ) dep is satisfied, > but kdelibs are build against nonexisting package Yes, IMO it's a problem - caused by using configure to detect the libraries available on the host system and building against them, instead of making the dependency specific according to user selection. I would expect removing a dependency would cause 'emerge -pv world' to cause the dependency to be pulled back in. Currently, however: USE="spell" emerge app-text/aspell emerge kde-base/kdelibs emerge -C app-text/aspell leaves you with a kdelibs that will fail when it tries to access libaspell, but: emerge -p world won't try to pull app-text/aspell back in again - when clearly it is a dependency of kdelibs as built. Normally if you unmerge a package that is a dependency from world, it would be built anew when you emerge world. If, however, the dependency included something along the lines of: aspell? ( || ( app-text/aspell app-dicts/aspell-en ) ) then 'emerge world' would pull aspell back in again if it had been removed. I'm not sure how the ispell dependency works; ispell does not provide any libraries, just the dictionaries themselves and a bunch of console apps to access them - thus perhaps that should be an RDEPEND anyway.
"aspell? ( app-text/aspell)" is perfect. No need for the aspell-en business.
Sorry but I don't understand all this. hspell is not even supported (allmasked) at present time, and spell flag + linguas_he could do easily the trick: spell? ( linguas_he? >=app-text/hspell-1.0 !linguas_he? ( || ( ( app-text/aspell ) app-text/ispell ) ) for the switching issue, users aren't supposed to switch their spelling mechanism every day, a warning at postinst of kdelibs is all what's needed...
I'm not really fond of the linguas_he approach, because it's not possible to mask hspell on arches where it does not work. And knowing the kspell support probably better than most of you show to know, I think I should say that both hspell, aspell and ispell are used with the commandline tools, not with libraries, by kspell. It's kspell2 that links aspell's library, but that is not used by anything and we might as well drop its support, as it's not complete for what I can see. This means that all of them can be simply merged at runtime and should work. So we can just remain with --without-hspell, that will disable the unused kspell2 plugin, and then leave the users needing hspell to use the proper kspell support that's actually used. by merging hspell by hand, whichever version. Is this good enough as a solution?
I just checked my system (kde 3.5.2) and nothing explicitly needs libkspell2 (apart from kspell_aspell and kspell_ispell which are also not explicitly needed by anything else). However, as plugins, I'd expect them to be linked dynamically at runtime via dlopen(), in which case they won't appear in DT_NEEDED lists - so they may still be used by something. Also, mine was built --without-hspell but the kspell2 stuff was still built (for aspell and ispell) - so to prevent kspell2 being built presumably you would need something else as well.
KSpell2 is not used by anything for what I've researched some time ago when I wrote a hunspell plugin for it. It's not even complete, so it's basically useless. The plugins will be loaded at runtime, but KSpell2 needs to be linked explicitly, so you can check by yourself that nothing uses it already. For this reason, there's no need for hspell to be enabled at build time in kdelibs; you can enable it if it's installed from the KSpell configuration. At the same time we could still use --without-aspell in the econf call and not loose any feature used by programs, that is spell checking inside KMail, Konqueror, KWord and so on. For this reason, I'd say this bug is entirely pointless, just stick with --without-hspell to avoid building the unused KSpell2 plugin, and thus fail to build when hspell < 1.0 is installed, and we're fine.
Thanks flameeyes for solving this :)
