Arch Linux User Repository

If you're getting compilation errors, please delete your Bazel cache (~/.cache/bazel by default).

Hi! I recently ran into an issue where I had to reinstall this package because the new release depends on mozc, which mozc-ut-common didn't provide pre-update, causing it do attempt to install the mozc package which conflicts with the former.

From looking at various PKBUILDs, it looks like you've become the maintainer of mozc and this change is to make the various framework module packages compatible with both mozc and mozc-ut-common. Am I then correct in assuming that the relevant packages going forward are the following?

• mozc and mozc-ut-common for the engine
• fcitx5-mozc-ut, ibus-mozc, and emacs-mozc for the modules

If I've understood correctly, there's no longer anything UT-specific about this package, and the names fcitx5-mozc and mozc-ut would have been used if not for the naming conflict with existing packages. Is this accurate?

(edit: I accidentally deleted my comment while initially trying to edit the formatting, sorry if you received multiple notifications.)

Thank you for your patience. I completely understand it now.

No such thing as a stupid question.

If you've managed to install this package then that means you are indeed using Mozc with the UT dictionary, as the latter is compiled into the Mozc binary during build time and used by default. AFAIK the only way to check for sure would be to compare the word candidates that this Mozc gives you with the candidates a non-UT Mozc would give you, but I don't really think that is necessary.

As to the second question: some time around 2016 the UT dictionary was deprecated by its creator in favor of two new dictionaries, UT2 and Neologd. They were supposed to replace UT, but in 2020 they were instead merged back into UT, and thus UT again became the de facto "UT dictionary" for Mozc. fcitx-mozc-ut-unified makes use of this latest UT dictionary, hence the "unified" part, which I assume was only added because there was already a package called fcitx-mozc-ut in the AUR (which was unmaintained at the time and was stuck using the old, pre-unification UT dictionary - this is no longer the case).

This package also uses the exact same UT dictionary, but because there weren't any Fcitx5 packages already in the AUR, I saw fit to just call it fcitx5-mozc-ut for consistency's sake (because from today's point of view, there is only a single UT dictionary). The only real difference between fcitx-mozc-ut-unified and fcitx5-mozc-ut is that the former is based on Fcitx, while the latter is based on Fcitx5, which is the Qt5-based successor of Fcitx. Do keep in mind though that Fcitx is still widely in use, as some language modules do not yet support Fcitx5 (e.g. the Baidu IME for Chinese).

Any *-ut2 packages can safely be considered as deprecated.

Sorry for my stupid questions cause I just learned about UT this week.

First, I installed this package using yay. However, there seems no differences in mozc. Do I need some config to enable UT dictionary? Or is there any methods to check if I'm using mozc with UT dictionary?

Second, there's seem to be multiple version of UT dictionary, such as fcitx-mozc-ut, fcitx-mozc-ut2, and fcitx-mozc-ut-unified in fcitx. I only find this package in fcitx5. I guess it's the same version as fcitx-mozc-ut-unified?

Apologies again for my stupid question.

@YEK

To be fair, utuhiro's PKGBUILD does have at least one advantage, namely, the fact that it doesn't rely on Fcitx's mirrored Mozc repo. I got bitten by this just now when, trying to update my mozc packages to their latest versions, I realized that while Mozc has been updated to version 2.26.4237 since 29/12/2020, the Fcitx mirror is still at version 2.26.4220.

This would normally mean that either I'd need to postpone updating this particular package (the ibus and emacs packages were already properly updated) and wait for the Fcitx developers to update their mirrored Mozc repo, or I'd need to update this package to only 2.26.4220 instead of the latest 2.26.4237 like the rest of the packages.

Enter utuhiro who, on top of providing UT in the first place, he also provides a patch for adding the needed Fcitx5 support directly to the upstream Mozc repo, without having to rely on the Fcitx devs to update their Mozc mirror. This patch literally saved the day.

So in fact I've now decided to modify my PKGBUILD to more closely resemble utuhiro's, by pulling directly from the official Mozc repo and using utuhiro's patch, along with the Fcitx5 iconset zip that he also provides on his website, in order to add Fcitx5 support on top of that.

I still think that the rest of the flaws I described, even though they're mostly minor, should really be addressed; but at least now we're even closer to convergence.

By the way, I'd welcome any suggestions you might have, now or in the future, for making this PKGBUILD better. We can always make the first step in fixing this non user-friendly AUR situation by cooperating ourselves :)

Thank you for the detailed explanation.

After deep consideration, I decided not to make an official PKGBUILD version and leave it to you.

Actually, I feel that the official PKGBUILD has a lot of changes and a lot of room for improvement. The variety of packages in Mozc is not user-friendly, and I think the idea is a very good one.

Thank you very much.

Hello @YEK,

Unfortunately, my choice to use a PKGBUILD different than the one provided by utuhiro is based on the fact that, as far as I can tell, there are a few flaws with it:

1. It doesn't pull the source files from either the official Mozc repo or the Fcitx projects's modified Mozc repo, instead opting to provide them via a separate download.
2. It contains outdated (e.g. pkg-config which has been replaced by pkgconf since 2018 or so), redundant (e.g. bzip2 which is a requirement of base and curl which is a requirement of pacman, both of which are installed by default on an Arch system) and/or missing dependencies (python-six).
3. It opts to depend on a system-wide gyp package, instead of making use of the included submodule.
4. In the same way, it doesn't use the included submodules for abseil, googletest, protobuf, or even the default Mozc dictionary itself, but instead provides them as separate downloads.
5. It builds and bundles all the Mozc binaries instead of only bundling the ones needed by Fcitx5 itself and depending on a separate package for the rest, and thus creates conflicts with other Mozc packages (e.g., one cannot install the Mozc package for Emacs if they have already installed the package for Fcitx5).

As such, at this time I think I prefer my own PKGBUILD instead of utuhiro's. I'm very open to the idea of collaboration between us and the rest of the various Mozc packagers in the AUR, and even with utuhiro, in order to create one common PKGBUILD template and use it to provide the whole gamut of Mozc packages (which would come with the added benefit that new users looking to install Mozc won't feel confused by the many different choices), but for the time being feel free to create a separate fcitx5-mozc-ut-unified package and I'll make sure to add it as an option in the ArchWiki's Mozc page (or you can also do it yourself, of course).

Thanks for contacting me, I appreciate it.

Hi, I'm maintainer of fcitx-mozc-ut-unified package. Now UT's upstream (utuhiro's project) supports fcitx5 officially with fcitx-mozc-ut-*-PKGBUILD.txt.

Will you follow it in this package? (If you won't, I will create fcitx5-mozc-ut-unified package.)