The ebuild currently includes in RDEPEND spell? ( >=app-text/enchant-1.6:0/0 ) As far as I can tell, I've actually had this version of pan working with enchant-2.2.3 since late January, but sometime since then, enchant-2.2.1 and higher switched to (or were always in?) subslot 2. So - after my emerge --update today, I had conflicts due to my installed pan requiring subslot 0 of enchant. Using all the ebuild steps, however, it compiled, installed, and works just fine. Given all the other work going on about enchant2, and particularly the possibility of using separate slots (see bug 654458) I'm not sure if just removing the subslot requirement would be ok for now (which is what I'll do with a copy put in my local overlay). I also don't know if this should be put in as a blocker for the tracking bug 629838. This problem obviously won't show up very often, because >=enchant-2.1.0 is still masked.
commit 0f2fa43fafe595afd5531cb114b474ffa8b1d079 Author: Mart Raudsepp <leio@gentoo.org> Date: Sat Apr 27 19:09:37 2019 +0300 net-nntp/pan: fix enchant dep pan does not work with enchant-2, lock it to SLOT=0 and also subslot 0 to cover p.masked unslotted enchant. Package-Manager: Portage-2.3.62, Repoman-2.3.12 Signed-off-by: Mart Raudsepp <leio@gentoo.org> commit 2304c225c1b68f0bf3ee5718009f4e6815a621c7 Author: Lars Wendler <polynomial-c@gentoo.org> Date: Thu Apr 25 15:31:19 2019 +0200 net-nntp/pan: Added subslot dep to app-text/enchant Package-Manager: Portage-2.3.64, Repoman-2.3.12 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>
What patching would that be?
pan can not possibly compile with its current configure script against anything >=enchant-2.1.3, thus the restrictions. Any other (older than 2.1.3) 2.x is ignored, because a) they aren't the latest p.masked version; b) well, they are p.masked. If you unmask enchant-2 without all this sorted, you get to deal with the fallout. The dependencies are as they are in pan because we support what's not p.masked; considering with older versions that are p.masked is not in the cards (I'd just remove them, but it can be considered as such due to p.mask anyways).
Oh _()&**^_ I just posted an explanation of what I had done, but I seem to have then closed the browser tab before seeing we had a mid-air collision. I'm also well aware I get to pick up the pieces from using masked packages. It turns out that although I did have Pan installed with Enchant-2.2.3, it silently compiled without spell support, since it didn't find a combination of gtkspell/enchant it could work with. That's my fault for not reading the build.log carefully enough. Question - if I set the spell use flag, but configure doesn't find gtkspell, is it right to let it continue without it, or should that get caught as an error? (Feel free to consider that a rhetorical question.) I'm closing this as INVALID (sorry for the noise) but wonder if there is a need for a wishlist bug for pan to be able to use enchant2. I am willing to convert this one or file a new one, but I suppose there is no point if it would only be sent upstream anyway, and I can as easily file it there directly.
We can pick up upstream patch based on a bug report downstream, yes. I very often end up fixing it downstream and filing patch upstream myself; sometimes I find something lingering in their merge requests/bugzilla or git unreleased too. For Gentoo it'd be a problem if something is "automagic" - USE flag enabled, but not honored. But it's a sufficient "fix" to ensure it'll always work as expected by depending on the necessary thing - as long as user having the USE disabled then doesn't automagically still enable it as the other way around to go wrong.
For upstreams the standard with autotools is that if a `feature` is explicitly requested with --enable-feature (or --enable-feature=yes for long), then if its deps can't be found, configure should error out. If --disable-feature (or --enable-feature=no for long) is passed, then it shouldn't check nor use those feature in that build conditional. If automatic support is coded (--enable-feature=auto but also usually if no explicit --enable/--disable for that feature isn't passed), then that can then check for the needed deps and preconditions and automatically enable or disable the feature based on if those are met. But as a distribution we need to be able to force it one way or the other to avoid outside influenced end results.
I understand that this is clearly not a Gentoo issue, but if I do an ebuild configure, I see ./configure includes --with-gtkspell but below is "checking for GTKSPELL... no" ./configure --help includes the line "--with-gtkspell enable GtkSpell support (normally: yes)" Does this mean it's actually optional, since it is --with-gtkspell and not --enable-gtkspell ? (and where should I be asking this, since it's not really relevant to the (non)bug?)
--with and --enable are the same thing in those terms. It's just a conceptual difference (--with implies building with some specific external dep, while --enable is about enabling some feature) An explicit --with-gtkspell passing should error out the build if not found, but it doesn't due to upstream suboptimal configure.ac coding indeed. For Gentoo, we workaround this by depending on the library, so it should always pass when --with-gtkspell is enabled. I'm not sure what's going on there for you that it doesn't. Upstream not properly erroring out then is what makes this often unnoticed on problems, but are usually corner-cases indicative of some weird issues with packages on the system or something. I'm not sure where you should be asking this. Maybe #gentoo-dev-help on freenode IRC if it has a Gentoo connection? I'm fine discussing things about packages I maintain (even if somewhat upstream related, but beneficial to Gentoo when handled) in whatever medium when I have some chat time.
In my case, it failed because I had p.unmasked enchant-2.2.3. Also, that was before the subslot 0 was added to RDEPEND, or if I removed it, so as you point out, restricting to :0/0 would work as expected. In my personal case, I changed the use flag to -spell because everything else I have that uses enchant has been patched to use the newer versions. Thanks for all the info.
