Packaging strategy for OpenBangla Keyboard

[mominul]

#202 Added the fcitx backend for OpenBangla Keyboard. As OpenBangla Keyboard will support two (iBus & fcitx) IM frameworks, we now have to figure out how we will package OBK from now on. I can think of two options:

• Remove the hard requirement of iBus in the packaging of OBK. OBK package will come with both ibus and fcitx integration. It'll be up to the user to install the IM (ibus or fcitx). Ubuntu(Gnome) comes with iBus as the default, so Ubuntu Gnome users will not have to think about IM frameworks.
• Have two separate packages of OBK, somewhat like openbangla-keyboard-ibus & openbangla-keyboard-fcitx.

@gunnarhj @Adyel @bdeshi @shakib609 @ahmubashshir

[Dyrimon]

I like the first choice. Managing two separate packages for OBK may create confusion in users. At install/setup stage the option for ibus/fcitx should tell the users which one will be better for them, i.e. "Use ibus for GNOME/Cinnamon etc and fcitx5 for KDE Plasma" . I don't know if installing both will cause any conflict. But I will leave it to you to make the decision to make the packaging stable. :) Kudos!

[gunnarhj]

Suppose you pinged me due to the plan to distribute OBK via Debian, so I'll comment with my Debian/Ubuntu hat on.

Ideally a user shouldn't need to think much about IM frameworks on any desktop environment. On Debian/Ubuntu we have a configuration package named im-config which takes care of launching the framework and setting the appropriate environment variables. So a user who wants to use an input method basically can:

• Install the IM engine package
• Relogin (reboot on GNOME)
• Add the IM engine, switch to it, and start inputting.

Personally I think it's unfortunate if the addition of Fcitx5 support results in a more complicated setup.

When it comes to distro packaging, it's important to distinguish between source package and binary packages. Given the new situation, it would be natural IMO to let the openbangla-keyboard source package build three binary packages:

openbangla-common
Everything except files specific to IBus or Fcitx5

ibus-openbangla
The IBus specific stuff — depends on openbangla-common and ibus

fcitx5-openbangla
The Fcitx5 specific stuff — depends on openbangla-common and appropriate Fcitx5 packages

A user would then just install either ibus-openbangla or fcitx5-openbangla. On another topic I mentioned mozc, and now I have a reason to do so again. 😄

https://packages.debian.org/source/sid/mozc

As you can see it builds quite a few binary packages. Not saying that so many packages would be needed for OBK; three packages is probably sufficient.

If you would follow this idea for the packages you provide directly in this github project, you would need to ask the users to install two packages instead of one. There are obviously other options. OTOH I suppose it's desirable to use the same package name(s) everywhere.

[mominul]

Personally I think it's unfortunate if the addition of Fcitx5 support results in a more complicated setup.

Yeah, that'd be a very bad situation. We had to add the fcitx support because ibus is very buggy and not well integrated on KDE.
Do you have any suggestions to avoid a complicated setup?

Package Splitting: I am fine with it if there is no other way available 😅 I have just a slight concern about the name of the packages, should we name those two ibus-openbangla-keyboard & fcitx-openbangla-keyboard or openbangla-keyboard-ibus & openbangla-keyboard-fcitx? But those seem quite verbose and ibus- & fcitx prefixes are prefered in other package names.

If you would follow this idea for the packages you provide directly in this github project, you would need to ask the users to install two packages instead of one. There are obviously other options. OTOH I suppose it's desirable to use the same package name(s) everywhere.

I create deb packages using CPack and I think creating a common package wouldn't be possible with it. But I think I could build separate packages for ibus & fcitx though.

[gunnarhj]

We had to add the fcitx support because ibus is very buggy and not well integrated on KDE.

I noticed #213, and it surprised me. While I'm not an input method user myself, I often help with installing and configuration matters, and have successfully made use of IBus on KDE (Kubuntu) multiple times. So I have a feeling that #213 is based on misconceptions, at least partly. (Note that I don't argue against Fcitx5 support. Such support will apparently make OpenBangla an attractive option for more users.)

Package Splitting: I am fine with it if there is no other way available 😅

I think there are several possible ways.

Your first option, i.e. simply dropping the dependency of ibus and let the users install either ibus or fcitx5 themselves, is indeed possible. But from my experience it's preferable to not bother the end users with the IM framework stuff; hence my suggestion about package splitting. At least on Debian/Ubuntu that would make it more like it works with other input methods.

I have just a slight concern about the name of the packages, should we name those two ibus-openbangla-keyboard & fcitx-openbangla-keyboard or openbangla-keyboard-ibus & openbangla-keyboard-fcitx? But those seem quite verbose and ibus- & fcitx prefixes are prefered in other package names.

Probably this is mostly about personal preferences. I generally like short names, and as you have noticed the names of other IM engine packages begins with the applicable IM framework. But I don't have any firm opinion here. I realize that openbangla-keyboard is an established name, and I can't see a problem if you prefer slightly longer package names.

I create deb packages using CPack and I think creating a common package wouldn't be possible with it. But I think I could build separate packages for ibus & fcitx though.

I see. Then you wouldn't be able to install both those packages on the same system, I suppose. But that's more like a theoretical problem.

Another option would be that we do it differently on github compared to Debian/Ubuntu. I mean you could choose your first option on github, and I could do the package split on Debian/Ubuntu only. Then I could simply let the Debian/Ubuntu packages conflict with the .deb package on github. A disadvantage with doing so is that it would require different installation instructions. OTOH however we do, the steps for installing OpenBangla won't be identical on github respective Debian/Ubuntu. So when thinking about it, possibly this would be the best option.

[ahmubashshir]

I think it'd be better to use ibus-openbangla instead of ibus-engine-openbangla for ibus engine. It's redundant.

[mominul]

@gunnarhj Sorry for the radio silence, I was busy with my final exams.
We have decided to use your first proposed naming of package splitting, ibus-openbangla, fcitx5-openbangla.
Do you need any build system changes in CMake for splitting packages?
I'll try to make a release within July. When the next freezing period of Ubuntu will start?

Thanks!

[ahmubashshir]

I already did that in aur :P Mubashshir

…

On Tue, Jun 29 2021 at 11:12:39 AM -0700, Muhammad Mominul Huque ***@***.***> wrote: @gunnarhj <https://github.com/gunnarhj> Sorry for the radio silence, I was busy with my final exams. We have decided to use your first proposed naming of package splitting, ibus-openbangla, fcitx5-openbangla. Do you need any build system changes in CMake for splitting packages? I'll try to make a release within July. When the next freezing period of Ubuntu will start? Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#219 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF5WM3SZHURL22VBTLA7B43TVIEJPANCNFSM44O5VIHQ>.

[gunnarhj]

Wise of you to prioritize your education, @mominul. 😄

Do you need any build system changes in CMake for splitting packages?

No, I can't think of anything. Assuming a source tarball similar to the one from which I could successfully build in a PPA, it should be possible to deal with the split in the distro package only.

When the next freezing period of Ubuntu will start?

Feature Freeze for Ubuntu 21.10 begins on August 19.

[ghost]

ভাই ওপেনবাংলা কি flatpak হিসেবে package করা সম্ভব ?
তাহলে প্রত্যেকটা distro এর জন্য আলাদা করে packaging করা লাগতো না

এমনও না যে Flathub এ আপ দিতে হবে বা এক্সট্রা dependency pull করতে হবে কোন runtime থেকে (for all the "bloat" people)
see : https://www.naps2.com/download

[ghost]

Is there any release date planned for OBK 3 ?
I might volunteer for packaging and maintaining OBK for Fedora, but I wanted to package/maintain both the ibus and fcitx versions for GNOME and KDE users respectively, but afaik OBK 2 doesn't have fcitx support and is old, thus I thinking waiting for a stable OBK 3 release would be better.
Targeting a stable branch instead of develop would be better in that regard to avoid potential breakage.

[mominul]

I have the intention to release OBK 3 by early January, wish me good luck!

[azrtareef]

@mominul sorry for reviving a dead discussion but I am really lost rn and don't know where to go. I am using the mangowm wayland compositor rn and I would like to use fcitx5 alongside it as ibus is kind of buggy in this environment. I would be extremely obliged if you could guide me to the right path to use it.

[codayon]

@azrtareef, when you use software in an unsupported or obscure environment, you usually have to find your own way to get things done. The maintainer might not even be aware of what MangoWM is. You could submit a feature request to support your environment, but whether it will be implemented is up for discussion.

Aside from that, if you want to use the Fcitx5 version of the application, you’ll need to build it from the develop branch, as the master branch only supports IBus. There are other discussions on similar topics you can check out. For example, this thread shows how to use OBK in Hyprland (with IBus?!). If you still can't figure it out, feel free to start a separate discussion on using Fcitx5 with MangoWM. If all else fails, you might want to fall back to a supported environment until you find the right way to configure your current setup.