On Fri, Oct 14 2022 at 12:54:53 PM +0200, Roland Rosenfeld <roland@debian.org> wrote:
Hi, let me try to summarize where we stand and what options and open questions we have. I see the following options to package the bdic-Files (seems not all of them were already mentioned before): a) Bundle the bdic files in the existing hunspell-<lang> files. - Pro: no new packages needed - Con: Duplicate size of existing ~80 packages b) Create new packages hunspell-bdic-<lang>. - Pro: User can install what is needed - Con: ~80 new packages necessary c) Add a mechanism to dictionaries-common, which extends update-dictcommon-hunspell to build the bdic file in hunspell-<lang>.postinst. - Pro: No changes in hunspell-<lang> - Pro: No redundancy in Archive - Con: Wastes space on users disk, unless QtWebEngine is used - Con: May slow down hunspell-<lang> installation- Con: Pulls in qtwebengine5-dev-tools for all hunspell-<lang> packagesd) Add a new package (hunspell-bdic-generator or the like), that builds bdic files for all hunspell-<lang> packages if it is installed. This requires some dpkg/apt-hook to trigger building bdic if a new hunspell-<lang> package is installed or upgraded. All packages using bdic files have to depend on hunspell-bdic-generator. - Pro: No changes in hunspell-<lang> - Pro: No redundancy in Archive - Pro: Only used/installed when needed - Con: Complex hook mechanism I'm not sure what option I prefer myself, they all have disadvantages, but I personally prefer b) over a), while c) and d) could reduce the effort for hunspell-<lang> maintainers (in trade-off to the efforts in dictionaries-common).
I don't have a strong opinion about a) vs b).
Except this I see the following open points:- Is bdic really arch:all or do we have some endiane issue? For optionc) and d) this is irrelevant.
There shouldn't be endian issues, as I mentioned elsewhere.
- Where should the bdic files be placed? 1) /usr/share/hunspell-bdic 2) /usr/share/qtwebengine-dict 3) /usr/share/bdic 4) /usr/share/hunspell
In my opinion, chromium's (, or QT's, or whoever's) bdic support should be merged upstream into hunspell, and hunspell should be shipping bdic files in /usr/share/hunspell alongside the .aff and .dic files. I don't know how active hunspell upstream is, though, and how amenable they'd be to patches. I see at least one person created an hunspell-with-bdic-support fork a decade ago: https://github.com/sheremetyev/hunspell
That would allow chromium and other hunspell users to link against a system hunspell when desired, dropping all the bdict versioning stuff and the custom paths. I'm pretty sure I could get a patch to link against system hunspell into chromium upstream, provided bdic support made it into upstream hunspell.
I wouldn't want to see debian carrying bdic patches in its hunspell package, though; nor would I want to see the security team needing to deal with a hunspell fork package.
5) something else (The order mentions my personal preference) - Is there some commandline client for auto-testing the bdic files? - How to reuse the bdic files with chromium? - 3 bugs in qwebengine_convert_dict reported by Soren Stoutner
I just took a peek at qtwebengine-opensource-src-5.15.10+dfsg, and I see that they're using the exact same hunspell fork from chromium. :(
- Do we target this this to bookworm or trixie? Greetings Roland