Hi Maxim, Maxim Cournoyer <maxim.courno...@gmail.com> skribis:
> Ludovic Courtès <l...@gnu.org> writes: [...] >>> That is equivalent, but it doesn't address the core problem in my >>> opinion. There's no use to run hooks for things which aren't propagated >>> at the level of the profile, I think. If texlive-base in is the >>> profile, the person wants to use tex and friends. But if it's wrapped >>> by some package deep down, we shouldn't care. >>> >>> I see it the same way as when using libraries and compilers in a >>> profile; the compiler (consumer) needs to be present else no search path >>> is created. >>> >>> Does it make sense? >> >> I agree with the reasoning; I think it doesn’t apply to the GLib schemas >> and GDK pixbuf caches though. > > It does, for the simple reasons that both GDK pixbufs and GLib schemas > are collected using manifest-inputs, which means only direct inputs from > the profile and the ones they propagate. So if you look deep in the > profile graph for the 'glib-compile-schemas' command, there is a chance > that it is found while no schemas were collected, and this is the kind > of case that'd lead to an empty derivation output (because there's no > schema to compile). Ah yes, that’s right. I was looking at it the other way around: GLib and GDK caches need to be built even if glib/gdk-pixbuf does not appear in the manifest. >> For TeX Live font maps, maybe it applies, though I’m not entirely sure >> (I wouldn’t be surprised if things other than ‘texlive-base’ are >> consumers of font maps). Plus, since the patch I proposed is simple, >> I’m inclined to just do that. >> >> Thoughts? > > I still think that my proposition is better, but I don't mind if you > apply your fix now and we revisit this at a later time. If we get to > it, this change could be reverted as it wouldn't be necessary anymore. Right. I pushed it as 916c6e5716bd14cb328f7dcce5405ba9100bb908. Thanks, Ludo’.