Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 685076 - app-text/enchant can and should be slotted (link to fixed ebuilds)
Summary: app-text/enchant can and should be slotted (link to fixed ebuilds)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-05 03:10 UTC by Daniel Robbins
Modified: 2020-02-02 19:47 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Robbins 2019-05-05 03:10:26 UTC
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.

Link: https://github.com/funtoo/kit-fixups/tree/master/text-kit/1.3-release/app-text/enchant
Comment 2 Mart Raudsepp gentoo-dev 2019-05-05 09:10:15 UTC
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.
Comment 3 Daniel Robbins 2019-05-05 18:26:25 UTC
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 :)
Comment 4 Daniel Robbins 2019-05-05 18:29:05 UTC
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.
Comment 5 Mart Raudsepp gentoo-dev 2019-05-05 22:28:03 UTC
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.
Comment 6 Daniel Robbins 2019-05-06 03:25:26 UTC
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.
Comment 7 Mart Raudsepp gentoo-dev 2019-05-06 07:58:22 UTC
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).
Comment 8 Daniel Robbins 2019-05-06 15:25:10 UTC
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+

OR

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.
Comment 9 Mart Raudsepp gentoo-dev 2019-05-06 19:50:04 UTC
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.
Comment 10 Daniel Robbins 2019-05-08 00:34:59 UTC
OK, feel free to reach out if you want to coordinate work on the GNOME stuff.
Comment 11 Larry the Git Cow gentoo-dev 2020-02-02 19:45:39 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a70335a18168bcc5ef283311f15fcb899aaa8456

commit a70335a18168bcc5ef283311f15fcb899aaa8456
Author:     Mart Raudsepp <leio@gentoo.org>
AuthorDate: 2020-02-02 19:42:33 +0000
Commit:     Mart Raudsepp <leio@gentoo.org>
CommitDate: 2020-02-02 19:45:20 +0000

    package.mask: Unmask enchant-2
    
    Now fully parallel-installable with enchant-1.6
    
    Closes: https://bugs.gentoo.org/685076
    Signed-off-by: Mart Raudsepp <leio@gentoo.org>

 profiles/package.mask | 4 ----
 1 file changed, 4 deletions(-)
Comment 12 Mart Raudsepp gentoo-dev 2020-02-02 19:47:01 UTC
gspell, gtkspell and gtkhtml enchant-2 versions remain masked right now until the above alluded stuff is figured out - but it seems all the gtkspell and gspell consumers are locked to enchant:0 for the time being, hence unleashed enchant-2 alone for now, with the rest to unmask after that mess is sorted out too.