From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: Trying to fix IBus Date: Thu, 11 Aug 2016 15:17:14 +0200 Message-ID: <8737mbcun9.fsf@elephly.net> References: <87lh04covy.fsf@elephly.net> <871t1vhf3y.fsf@gmail.com> <878tw3d34a.fsf@elephly.net> <877fbn1suv.fsf@gmail.com> <874m6rcuun.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54452) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXprR-0000Bb-Dq for guix-devel@gnu.org; Thu, 11 Aug 2016 09:17:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bXprN-0008LF-64 for guix-devel@gnu.org; Thu, 11 Aug 2016 09:17:24 -0400 Received: from sender163-mail.zoho.com ([74.201.84.163]:24006) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXprM-0008L3-Sy for guix-devel@gnu.org; Thu, 11 Aug 2016 09:17:21 -0400 In-reply-to: <874m6rcuun.fsf@elephly.net> 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: Chris Marusich Cc: guix-devel Ricardo Wurmus writes: > Chris Marusich writes: > >> 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. > > Right, I saw that too, but I really don’t think it applies to us. I’m > not familiar with the state of IBus in NixOS before the change to > NIX_PROFILES, but I don’t see how this would break existing software. > > The reason for crashes is that GTK2 software is made to load GTK3 input > method modules (and vice versa). We don’t set any variables right now > that could have this effect. When adding the “GUIX_GTK{2,3}_*” > variables, software built with the unpatched GTK would just ignore input > methods. > > If I understand correctly, NixOS installs (or used to install) IBus > system-wide and has system-wide caches (at /etc/…/immodules.cache). Our > caches would exist on a per-profile base. > > If you are more familiar with this problem in NixOS and you think I’m > overlooking something I’d be happy if you could show me what I’m > missing, but I really think that we wouldn’t be bitten by a problem like > this. In our case software using the pre-patch GTK versions would > behave just like they do now: simply without IBus support. One more thing: we could also preempt the decision of GTK upstream and hardcode IBus as the only possible input method system (as has been suggested on the NixOS discussion), but I think that we should rather avoid patching things more than absolutely necessary. (Some people prefer fcitx over IBus; I don’t want to force them to migrate to IBus when there’s a simple alternative.) ~~ Ricardo