On Friday, October 28, 2022 4:09:45 AM MST Agustin Martin wrote: > I am not particularly happy about this (see details below), but seems > we will have to package all these .bdic files because qtwebengine and > chromium use them. Since some .bdic may fail to build I would rather > prefer them to be generated during package creation, where it is > easier not to create them if required. If done during package install > I think everything should be handled from qtwebengine package. In this > case some fine tuning can be done to improve efficiency (handling > symlinks better, regenerate only when a new version of dict package is > installed or incompatibilities in qtwebengine hunspell appear, ...) I agree with you. I am also unhappy that Chromium and QtWebEngine want to use a specialized file format instead of just using the standard Hunspell files. However, as much as I don’t like it, I also agree with you that the best thing Debian can do in the short term is to move forward with the packaging of these .bdic files while we wait to see if we can make any changes upstream. Given that nobody else responded to this question, I think there is a consensus that it is best to create the .bdic files during package creation. The next question that needs to be answered is if we should create new binary packages for the .bdic files or if we should ship them as part of the existing Hunspell language binary packages. The opinions that have been expressed so far have run the gamut on both sides, but my sense is they lean a little towards shipping them in the existing Hunspell packages so as to not add 80+ new packages to Debian that only contain a few files each. Is there anyone who feels strongly that they should not be shipped in the existing files? -- Soren Stoutner soren@stoutner.com
Attachment:
signature.asc
Description: This is a digitally signed message part.