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:12:48 +0200 Message-ID: <874m6rcuun.fsf@elephly.net> References: <87lh04covy.fsf@elephly.net> <871t1vhf3y.fsf@gmail.com> <878tw3d34a.fsf@elephly.net> <877fbn1suv.fsf@gmail.com> 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]:53769) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXpnD-00073J-EM for guix-devel@gnu.org; Thu, 11 Aug 2016 09:13:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bXpn8-0007Uc-R0 for guix-devel@gnu.org; Thu, 11 Aug 2016 09:13:02 -0400 Received: from sender163-mail.zoho.com ([74.201.84.163]:24565) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXpn8-0007Tw-Iy for guix-devel@gnu.org; Thu, 11 Aug 2016 09:12:58 -0400 In-reply-to: <877fbn1suv.fsf@gmail.com> 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 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. ~~ Ricardo