Hi Ludovic, Ludovic Courtès <l...@gnu.org> writes:
> Hi, > > Maxim Cournoyer <maxim.courno...@gmail.com> skribis: > >>> There were cases (like GDK pixbuf, GLib schemas, and all that) where the >>> idea >>> was to take whichever glib/GDK we’d find in the dependency graph, and >>> pick the command we need from it. That way, we wouldn’t introduce any >>> additional dependency. That was the reasoning. >>> >>> Thinking about, this particular case might be easier: we can make things >>> consistent like so: > > [...] > >>> + (if (and texlive-base (pair? texlive-inputs)) >>> (gexp->derivation "texlive-font-maps" build >>> #:substitutable? #f >>> #:local-build? #t >>> >>> >>> That way, the hook only fire if we have ‘texlive-base’ (somewhere in the >>> graph) *and* we have texlive-* packages in the manifest. >> >> 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). > 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. -- Thanks, Maxim
