I have an annoying little problem with IBus. IBus creates a binaryregistry in ~/.cache/ibus/bus on first start(?) which contains the fullpaths to store items such as /gnu/store/k3r...-ibus-1.5.11/libexec/ibus-dconf The problem is that when updating the “ibus” package this registry isinvalid, but never invalidated or regenerated. IBus will continue touse the paths in the registry — even after they have disappeared after“guix gc”. This results in an unhelpful error when starting“ibus-setup”: Can not execute default config program This is because it tries to run “$oldstoreitem/libexec/ibus-dconf”,which has been removed by garbage collection. The “.cache” directory is not part of the profile, of course, so wecannot automatically rebuild it. Looking at the code it seems that IBusfirst looks for a system registry, but this registry cannot be right asthe user may have installed additional IBus input methods and the systemregistry (wherever that may be) is not writeable. Should we prevent a registry in the “.cache” directory to be used andtry to make IBus look for a registry that could be generated as part ofgenerating a new profile generation? ~~ Ricardo
Toggle quote (6 lines)> I have an annoying little problem with IBus. IBus creates a binary> registry in ~/.cache/ibus/bus on first start(?) which contains the full> paths to store items such as>> /gnu/store/k3r...-ibus-1.5.11/libexec/ibus-dconf
GIMP has a similar problem for files in ~/.gimp-2.8, though it seems toautomatically regenerate them or something.
Toggle quote (4 lines)> Should we prevent a registry in the “.cache” directory to be used and> try to make IBus look for a registry that could be generated as part of> generating a new profile generation?
Either that or we change the IBus code to detect stale caches and getrid of them. This might even be acceptable upstream. WDYT? Ludo’.