On Fri, Oct 14 2022 at 12:54:53 PM +0200, Roland Rosenfeld
<rol...@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>
packages
d) 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
option
c) 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
