app-text/enchant in Gentoo really can and should be slotted, and it is easy to do. In fact, instructions are given in the source code on how to do it. For Funtoo, we've slotted these ebuilds so they can co-exist (1.6.x and 2.2+). Version 2.2 has major changes compared to the previous versions so we have set SLOT=2.2 for 2.2+. SLOT=0 for versions 1.x to maintain compatibility with Gentoo. Please, feel free to pull these changes into Gentoo. It will allow enchant-2.2 and enchant-1.x to exist on the same system happily and should allow easy fixing of a lot of related issues.
Yes, looking into it is why enchant-2 is still p.masked.
I don't think it's as simple as just providing the slots - need to care for an application not ending up with both enchant versions loaded in the process via its own enchant usage and/or its libraries using them. So some mapping of what libraries use enchant and making sure no application can end up with conflicting libraries vs enchant version.
If this all pans out, in Gentoo the SLOT will be whatever the pkg-config file version is. I'm quite sure that isn't 2.2.
I've already done research on this and actually did a couple of youtube videos on this if you're interested (not that it matters, but you can see my troubleshooting process: https://www.youtube.com/playlist?list=PL2YVrx9jFJOe70YS_15nSO50bos30Be8I)
The basic situation is this -- at version 2.2, they did a rename of pkgconfig files so they are "enchant-2.pc" instead of "enchant". Same with the library. "libenchant-2.so". I have checked in Debian unstable and version 2.1 (before 2.2 of course) is still "enchant.pc". So the split is definitely at the 2.2 point.
The way the ebuilds I linked to in funtoo are set up have everything in 2.2.3 using the "enchant-2" name so there are no file conflicts with enchant prior to 2.2.
Hope that helps. Watch the videos and you can see me stumble through figuring this out :)
From my research (covered in the video), the developer convention appeared to be that packages that used 2.2+ would explicitly look for "enchant-2.pc" whereas those that wanted earlier versions would look for "enchant.pc". So I think this is what all the upstream sources that link to enchant are doing.
Yes, that's the case (pkg-config package names; except it got parallel-installable with enchant-2.pc with version 2.1.3 and beyond, not 2.2.3, afair).
Gentoo will reflect the pkg-config version as SLOT name as usual (if it is made parallel-installable), thus SLOT=2.
But it's not at all what I said in #c2 as being the potential trouble from parallel-installable versions of enchant.
OK, well I guess I don't understand exactly what you are saying re: comment 2 -- I think that if the package utilizing enchant gets the correct pkgconfig file, it will get the correct includes, and link and use the correct lib and files since there is no overlap. So it should be fine. I am happy to follow Gentoo's lead re: slots if you want to get these slotted and use "2" for SLOT.
I'm talking about cases like an application linking to both enchant-1 and gspell; now gspell gets upgraded to the version that uses enchant-2 instead of enchant-1 (because it gets unmasked). Now the application at startup loads both enchant-1 and enchant-2 library into the process by dynamic linker, and there may be a mess of symbol shadowing and applications own enchant usage ending up using enchant-2 (even though it was linked against enchant-1), or new gspell ending up using enchant-1, even though it was compile time linked against enchant-2. This can cause all sorts of unknown mess at runtime.
So if this isn't a problem in practice, great, I'll know to not worry about it much. If it hasn't been thought about yet, should map some deptrees where libraries using enchant are involved and at least ensure that a fully updated system without mixed keywords doesn't end up with two different enchant in the deptree, but probably don't need to worry about mixed keywords and such ending up with subtle problems.
In practice it's not a huge issue, just need to get to all this, but there was a huge backlog with GNOME and such, which took the time without getting to enchant (as 3.30 works with old enchant too).
Ah, I see. I can tell you how net-nntp/pan handles it since I looked at its configure.ac script. IF gtk3+ is enabled, THEN it will consider using gtkspell. When it is using gtkspell (if enabled via configure) THEN it sees whether it has gtkspell3-3.0.pc -- if so, it will use gtkspell 3 and enchant-1.6+, and if not, it will use gtkspell-2.0 and enchant-1.6.
In funtoo, I patched this so it just uses enchant-2 always.
But in theory, if you wanted to have things be sane but handle both options, you could tweak configure.ac so that it will use either:
gtkspell3-3.0 + echant-2.2+
gtkspell2 + enchant
This would seem to be a sane set of options.
The configure.ac script does require a tiny bit of tweaking to make this perfect and avoid having gtkspell + enchant using diverging libs, but it is not a hard tweak and we are not even sure if it causes problems :) but probably best to avoid.
My suggestion would be officially supporting the two combos listed above since it seems reasonable. So don't support gtkspell-3 + enchant-1.x or gtkspell-2 + enchant-2.2+. Then we just make sure any ebuilds that use both 'do the right thing' and follow these rules.
gtkspell != gspell from my example, though; there it was 1.6 vs 1.8 version iirc, with just an upgrade with the same pkg-config for gspell.
Bottom-line - just need to get to it. But GNOME 3.30 stabling and a couple smaller things first.
OK, feel free to reach out if you want to coordinate work on the GNOME stuff.