From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: Trying to fix IBus Date: Thu, 11 Aug 2016 03:51:20 -0700 Message-ID: <877fbn1suv.fsf@gmail.com> References: <87lh04covy.fsf@elephly.net> <871t1vhf3y.fsf@gmail.com> <878tw3d34a.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48408) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXnaE-0000in-9b for guix-devel@gnu.org; Thu, 11 Aug 2016 06:51:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bXnaB-0006we-MO for guix-devel@gnu.org; Thu, 11 Aug 2016 06:51:29 -0400 Received: from mail-pf0-x229.google.com ([2607:f8b0:400e:c00::229]:35585) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXnaB-0006vq-Bm for guix-devel@gnu.org; Thu, 11 Aug 2016 06:51:27 -0400 Received: by mail-pf0-x229.google.com with SMTP id x72so25750866pfd.2 for ; Thu, 11 Aug 2016 03:51:27 -0700 (PDT) In-Reply-To: <878tw3d34a.fsf@elephly.net> (Ricardo Wurmus's message of "Thu, 11 Aug 2016 12:14:13 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: guix-devel --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ricardo Wurmus writes: > Chris Marusich writes: > >> Ricardo Wurmus writes: >> >>> NixOS encountered the same problem: >>> >>> https://github.com/NixOS/nixpkgs/pull/14568 >>> >>> I don=E2=80=99t like their solution to set a variable NIX_PROFILES and = let GTK >>> look for immodule files in each of the directories. >> >> Why don't you like their solution? Why do you believe that your >> proposed solution is better than their solution? We should make sure to >> choose the best solution available, and right now I'm not sure which one >> is better. > > I find it very inelegant to ask users to specify a list of directories > containing profiles. A mechanism like that also seems like a hack to > me, and I=E2=80=99m afraid that we would begin to rely more and more on t= his to > =E2=80=9Csolve=E2=80=9D other problems. > > Splitting a variable that GTK is already using anyway into two different > versions just seems a lot cleaner to me. The variable won=E2=80=99t even= need > to be exposed to most users; we could set it automatically when > generating profiles. > > Eventually this will disappear once the GTK devs retire support for > separate input method modules (I guess this would make IBus a hard > dependency on GNU systems). At that point we can easily drop our > patches and the profile hook; a generic GUIX_PROFILES variable, on the > other hand, would be more difficult to deprecate if it becomes more > popular (as it has a much broader scope). That makes sense. I think these are good reasons to favor your solution instead of the NixOS solution. I think your plan is good. >>> Instead, I think we should patch both GTK versions to respect >>> GUIX_GTK2_IM_MODULE_FILE and GUIX_GTK3_IM_MODULE_FILE, and generate >>> the immodule cache files in a profile hook. >>> >>> We did something similar before with GUIX_GTK2_PATH and GUIX_GTK3_PATH. >> >> I believe you are referring to this thread: >> >> https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00046.html >> >> Did that patch actually get committed? If so, why didn't it solve the >> problem? I've read all the relevant discussions I could find [1], and >> it isn't clear to me why we need to do what you're suggesting ("patch >> both GTK versions to respect GUIX_GTK2_IM_MODULE_FILE and >> GUIX_GTK3_IM_MODULE_FILE, and generate the immodule cache files in a >> profile hook") if we've already committed the patch presented in the >> thread above. > > Yes, that patch got committed and it actually solved a problem. It is a > different problem, though. GTK really assumes modules to be in one > place, which means that with immutable directories we have no other way > to make things work. I see. I guess I just wasn't familiar with the other issue. Thank you for explaining. One last thing: it seems that the NixOS devs' choice of solution was influenced by a desire not to require users to rebuild programs that were previously installed in their profiles [1]. They almost chose a solution like the one you are proposing, but they changed their minds to avoid requiring users to rebuild existing programs in their profiles. GuixSD is still Beta, so I don't think that's an issue for us at all. [1] See abbradar's comment on April 8th, 2016: https://github.com/NixOS/nixpkgs/pull/14417#issuecomment-207362530 "This patch would break all such software that uses old (unpatched) GTK+3." This appears to be the primary reason why they chose to patch GTK+2 and GTK+3 to search NIX_PROFILES for an immodules.cache file instead of patching it to use separate environment variables for GTK+2 and GTK+3. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXrFiqAAoJEN1AmhXYIkadrDYP/0sSsCWX/rgxdBqbyHL++lnr AJyCwtKNNe0DM6g9WD7kmIoUs3/LyrtcHgf1R/k1nHmU1/s8kn2JbCzZO5+8AkcM QCKv2kE11rYCxMVRY8C4j7svRdkcZ6GdR+VHQfIGdp75hVAdOnDZLeH26nK06qiF T+dBx7KFuKy0/08BWz08r3UUdqHe00bNiRXRc5ZtywrkyaPK2I+EXYogRG93IJcl VUwoq+5Ds/6hjeLMBcMdIfFtlYolHavOGgTwkfeR5u/xb5YoJpUje7LpOa2OWBWZ Cp8gQPuQISaJc1vBD3z6lc2nIkpEgO3L7necFucqdq5/Xu516zvp/u8RqRHodlJu OHDCz3twbRn7fIF8cXHtku0RQ4tWaU/QpLMlOe+IOH16tuy8S2hBrAxJARy6O5x+ IWoo5V4WZJpamvtq5Z/Nm/bw+39F9ZlcuPOzK2KFVdN5c8ukL3FPwCPYQYhP+YXP 0f3R2hEdKqnLEXND1HFCdXhWZRAMpNYfXwGJxhrKbaIVOStGOm/b6ooIRgpYMqz7 I5xk59pozwH+0NIhZScV+6GQOE4rUT+WY4A6HEEO9PP+3THJr+1Sg/hleI2pgNlp cUdtvWFARaLYZRa1QOibgulKwSei6khBxVTJ/l71kUr8mQnGnht+Zwtdd9miWsSJ eoMKqh1/GTiw47T1CUMQ =e8QO -----END PGP SIGNATURE----- --=-=-=--