Hi Ludo,

On Wed, 16 May 2018 10:57:57 +0200
ludo@gnu.org (Ludovic Courtès) wrote:

> Since “fixing” packages like you just did is a manual step, I think it’s
> still fine to ignore “icon-theme.cache” collisions.  WDYT?

Definitely.

> > However, about gschemas.compiled I'm not sure yet.
> >
> > How do we ensure that glib-or-gtk-build-system is actually used for packages that
> > need it?  
> 
> I don’t think we can.  :-/
> 
> > libreoffice has some problem that makes it crash every time it tries to open a
> > file dialog - I wonder if that's related (libreoffice uses gnu-build-system).  
> 
> It is, see <https://bugs.gnu.org/30642>.
> 
> > But glib-or-gtk-build-system expicitly generates gschemas.compiled, ensuring a
> > collision - what's up with that?  
> 
> glib-or-gtk-build-system wraps binaries so that they refer to the right
> gschemas.compiled, so in that case the gschemas.compiled file that ends
> up in the profile doesn’t matter at all.
> 
> > Shouldn't there be a profile hook for it instead?  There doesn't seem to be one.  
> 
> Maybe, yes, though I’m not sure how that’d work (and would it be fast
> enough?).

I wrote one in bug 31462.  Seems to be quite fast.  But let's think about whether
we want it, and whether we want it in addition to the wrapper.

(libreoffice works with it now FWIW)

> This seems to be orthogonal to this patch, though: we can remove the
> collision warnings for these files today, because there’s nothing users
> can do about them and they’re effectively harmless, and later on, if we
> have better gschemas.compiled handling, we can always let them through
> again.

Yeah, I just wanted to make sure we are not hiding them if they are the only
indication that something will break horribly with the program.
(see libreoffice)

But since the wrapper needs gschemas.compiled, we can't use it as indicator
for missing-glib-or-gtk-build-system anyway, so:

LGTM!