Sure, this multiple per-engine packaging approach, where each package is built by disabling all engines except one of them and depends on its corresponding backend engine is the correct solution.

Before submitting the enchant-pure package, I filled a bug here: https://bugs.archlinux.org/index.php?do=details&action=details.addvote&task_id=31807

At that time (about ten year ago), the official enchant package did depend on three backend engines and my reported bug was rejected by Jan de Groot as he thought removing backends may force users of those backend engines to "re-build" the enchant package.

Then I submitted enchant-hspell and enchant-pure AUR packages and exemplified that how these packages can be created so end-users may simply install binary packages and enable engines one by one.

Maybe, currently that maintainer of the enchant package has changed to Antonio Rojas and those required dependencies are removed, they accept to create per-engine packages. I think we should keep the AUR packages until they are adopted in the extra repo.


Nevertheless, we cannot ignore those warnings because they indicate that relevant .so files are installed. That is, the current enchant package actually depends on all those backend engines and marking them as optional dependencies is just wrong packaging.


On 11/11/23 20:49, Marcell Meszaros wrote:
Hi,

Based on what you wrote, I surmise that shared library import warning logs are irrelevant for users, and those warnings can also be filtered out from system logs when debugging real problems.

So it leads me to conclude that this package is not sufficiently useful to users to justify having this lesser-functionality duplicate in AUR.

If the reported warnings have relevant detrimental effects, I suggest that you file an Arch bug ticket. Also, repo's enchant could solve this issue by making a split package of it, and putting each spell checking engine related .so library in separate subpackages, which in turn should each depend on their respective engine library, with the main enchant package optdepending on these engine-specific split 'enchant-*' packages.


On 11 November 2023 17:57:05 GMT+01:00, Behnam Momeni <s.b.momeni@gmail.com> wrote:

Greetings MarsSeed and Marcell,


The enchant-pure is more "pure" than extra repo's version because it is built by disabling all backends, but the aspell and hunspell which allow all languages to be enabled/disabled selectively. If we install those other backends, they will be detected and used at runtime with no issue too (as demonstrated by the enchant-hspell AUR package).

However, the extra repo's version is built by enabling all backend engines. Therefore, even when those backends are not installed, the built enchant contains those (missing) dependencies binding.

This problem can be seen by running "gedit" as an example enchant client, after installing the extra repo's version of enchant package, and watching its warnings in the console (open gedit with the enchant-pure version and no such warning will be printed):


(gedit:6143): libenchant-WARNING **: 20:05:16.243: Error loading plugin: libvoikko.so.1: cannot open shared object file: No such file or directory

(gedit:6143): libenchant-WARNING **: 20:05:16.243: Error loading plugin: libnuspell.so.5: cannot open shared object file: No such file or directory

(gedit:6143): libenchant-WARNING **: 20:05:16.243: Error loading plugin: libhspell.so.0: cannot open shared object file: No such file or directory

(gedit:6143): libenchant-WARNING **: 20:05:16.259: Error loading plugin: libvoikko.so.1: cannot open shared object file: No such file or directory

(gedit:6143): libenchant-WARNING **: 20:05:16.260: Error loading plugin: libnuspell.so.5: cannot open shared object file: No such file or directory

(gedit:6143): libenchant-WARNING **: 20:05:16.261: Error loading plugin: libhspell.so.0: cannot open shared object file: No such file or directory

On 11/11/23 12:30, Marcell Meszaros wrote:
Actually this has not one, but two more mandatory spell checker library depends compared to repo's enchant. So it is even more "impure", to coin this package's weird choice of qualifier suffix.

On 11 November 2023 09:49:08 GMT+01:00, notify@aur.archlinux.org wrote:
MarsSeed [1] filed a deletion request for enchant-pure [2]:

Unneeded duplicate of extra/enchant, with misleading name.

This is less "pure" than extra repo's package, because it has one more
mandatory depends than the latter.

The repo package defines its dependency on all spell checking engines
as optional.

[1] https://aur.archlinux.org/account/MarsSeed/
[2] https://aur.archlinux.org/pkgbase/enchant-pure/
-- 
Best Regards,
Behnam Momeni
-- 
Best Regards,
Behnam Momeni