The compose tables in /usr/share/X11/locale/<locale>/Compose which describe how keys are composed (for example '<accent-acute>' and 'e' yield 'é') are currently bundled with x11-libs/libX11 although they are orthogonal to the library. x11-terms/alacritty, for example, fails to compose keys because it, being a Wayland application, is installed without libX11 but would require its compose tables. I think the least favorable solution is to make anyone (be it libxkbcommon or the latter's user) depend on libX11 just for these compose tables. The compose tables should, in my opinion, preferably be - split out into a distinct package, or - bundled with a more reasonable packages, suggesting x11-libs/libxkbcommon
(In reply to Cedric Sodhi from comment #0) > The compose tables in /usr/share/X11/locale/<locale>/Compose which describe > how keys are composed (for example '<accent-acute>' and 'e' yield 'é') are > currently bundled with x11-libs/libX11 although they are orthogonal to the > library. > > x11-terms/alacritty, for example, fails to compose keys because it, being a > Wayland application, is installed without libX11 but would require its > compose tables. > > I think the least favorable solution is to make anyone (be it libxkbcommon > or the latter's user) depend on libX11 just for these compose tables. > > The compose tables should, in my opinion, preferably be > > - split out into a distinct package, or > - bundled with a more reasonable packages, suggesting x11-libs/libxkbcommon How do other distributions handle this? What you're proposing is an upstream solution and not really something I can easily do in Gentoo.
>How do other distributions handle this? I don't think that other distributions have that problem, since they don't allow being 'Wayland purist' and live without libX11. On something like Arch Linux, they are also part of libX11 afaics. >What you're proposing is an upstream solution and not really something I can easily do in Gentoo. The problem is only in locale and keyboard files, and for downstream the solution could be to embed compose tables like gtk does, but that's a lot of work, and I doubt small and simple C application will ever do that. Those files live entirely in /usr/share/X11/locale, and I guess that's the only directory that is required for them to work ( I see stating of /usr/share/X11/xkb, but I don't see that anything is read from it). So the thing that could make downstream happy is that /usr/share/X11/locale will be brought by some other package, which could be installed only under some special use flag on libxkbcommon or always by default. One more thing that I'd like to mention that libxkbcommon allows you to point on locale files by using XLOCALEDIR[1], so if collision is a problem, you may just have a package that brings them and then user selects locale folder they'd like to use. [1] - https://xkbcommon.org/doc/current/group__compose.html#gadf23e7ee37c26aa0fc68ffc1213349ea
So to summarize with Kirill's methode there are at least these options for the compose tables 1. Leave them in XLib 2. Strip them from XLib, add them to "x11-libs/compose-tables" under the standard directory, have XLib depend on "x11-libs/compose-tables" 3. Add them to "x11-libs/compose-tables" which BLOCKS XLib 4. Add them to "x11-libs/compose-tables" under a non-standard directory, add "XLOCALEDIR" to the environment in a pkg_postinst 5. Add them to "x11-libs/compose-tables" under a non-standard directory, configure x11-libs/libxkbcommon using meson option "x-locale-root" cross-producted with a. Have users depend on the according package b. Have x11-libs/libxkbcommon depend on it I noticed there is a libxkbcommon-1.0.1-r1.ebuild, but I suppose that doesn't change anything?
(In reply to Cedric Sodhi from comment #3) > 2. Strip them from XLib, add them to "x11-libs/compose-tables" under the > standard directory, have XLib depend on "x11-libs/compose-tables" Can you give this one a try?
I've just checked some other distros that uses Wayland by default, and it seems like fedora provides a custom package for just locales from libX11, it's called libX11-common[1]. So it seems like there's at least one distro that is splitting those things already. AFACS libX11-common is only required for libX11 on fedora, however in gentoo there could be a use flag for libxkbcommon to provide a compose tables. So we may take a look on it to get inspiration on how to do that. We may call it a bit different, to say that it's not X11 specific. [1] - https://fedora.pkgs.org/32/fedora-aarch64/libX11-common-1.6.9-3.fc32.noarch.rpm.html P.s. I can't provide link other than that, since other packages source for fedora is down for me, however I've checked in fedora vm, that /usr/share/X11/locales belong to different file.
After a lot of help from #gentoo-dev-help... I left the Compose(5) in libX11 and do not prevent the latter from compiling the locales. There is a --disable-xlocale configure flag, but I did not dare touch it because it sounds (marked "*EXPERIMENTAL*") like it changes things in the library itself.
Created attachment 666497 [details] x11-misc/compose-tables-1.6.12
Created attachment 666500 [details] x11-libs/libX11-1.6.12
Probably needless to say, but please check that my understanding of this is correct. I isolated the entire contents of libX11's /usr/share/X11/locale into x11-misc/compose-tables. Possibly, the latter... ...should only take parts of that directory ...better be called "libX11-nls" or something similar
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b9ab8d410b201f244f075e2168a7829db487f693 commit b9ab8d410b201f244f075e2168a7829db487f693 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2020-11-21 01:57:30 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2020-11-22 21:15:58 +0000 x11-libs/libX11: Version bump to 1.7.0 Thanks to Cedric Sodhi for figuring out how to split the compose-tables out into a separate package. Closes: https://bugs.gentoo.org/749576 Signed-off-by: Matt Turner <mattst88@gentoo.org> x11-libs/libX11/Manifest | 1 + x11-libs/libX11/libX11-1.7.0.ebuild | 38 +++++++++++++++++++++++++++++++++++++ 2 files changed, 39 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=96df73c751c675389842e539643e930969db06e2 commit 96df73c751c675389842e539643e930969db06e2 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2020-11-21 02:14:59 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2020-11-22 21:15:58 +0000 x11-misc/compose-tables: Add split package Closes: https://bugs.gentoo.org/749576 Signed-off-by: Matt Turner <mattst88@gentoo.org> x11-misc/compose-tables/Manifest | 1 + .../compose-tables/compose-tables-1.7.0.ebuild | 41 ++++++++++++++++++++++ x11-misc/compose-tables/metadata.xml | 11 ++++++ 3 files changed, 53 insertions(+)
I removed the sed'ing from compose-tables' ebuild because I don't want to have to maintain that. Please get a patch into upstream to allow the build system to only build/install the compose-tables if you desperately want to avoid those build-time dependencies.
Hard blocker is really necessary?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=604087aac5755d6a0e5a360eb6c4dcd1afbaac52 commit 604087aac5755d6a0e5a360eb6c4dcd1afbaac52 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2020-11-22 22:24:15 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2020-11-22 22:24:38 +0000 x11-misc/compose-tables: Change from hard to soft blocker Bug: https://bugs.gentoo.org/749576 Signed-off-by: Matt Turner <mattst88@gentoo.org> x11-misc/compose-tables/compose-tables-1.7.0.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
(In reply to Matt Turner from comment #11) > I removed the sed'ing from compose-tables' ebuild because I don't want to > have to maintain that. > > Please get a patch into upstream to allow the build system to only > build/install the compose-tables if you desperately want to avoid those > build-time dependencies. FWIW I understand your relucance to put up with the finicky sed-line, just, given the past evolution of Xlib's `configure.*`, I figured chances that this will break any time in the foreseeable future are somewhat negligible. OTOH, upstream accepting a switch on libX11 which essentially says "--disable-libX11" is probably even less likely... I'll mention it on their GitLab anyway. Thanks for the improvement!
I think there is still a decision to be made how this dependency is then handled where it is relevant. I.e. should libxkbcommon depend on compose-tables or or should the respective users (e.g. alacritty) issue a dependency when needed (I suspect there exist users of libxkbcommon -- like gtk+ -- which do not require compose-tables).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=640dbeb0f4bc62767daec1b31a053dd9c0bccff7 commit 640dbeb0f4bc62767daec1b31a053dd9c0bccff7 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2020-11-25 16:13:45 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2020-11-25 16:19:28 +0000 x11-libs/libxkbcommon: Version bump to 1.0.3 Add RDEPEND on x11-misc/compose-tables too (bug #749576). Bug: https://bugs.gentoo.org/749576 Closes: https://bugs.gentoo.org/756295 Signed-off-by: Matt Turner <mattst88@gentoo.org> x11-libs/libxkbcommon/Manifest | 2 +- .../{libxkbcommon-1.0.2.ebuild => libxkbcommon-1.0.3.ebuild} | 1 + 2 files changed, 2 insertions(+), 1 deletion(-)
