Re: Trying to fix IBus

[Ricardo Wurmus <rekado@elephly.net>]

Chris Marusich <cmmarusich@gmail.com> 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