Ludovic Courtès <l...@gnu.org> writes:
> 宋文武 <iyzs...@gmail.com> skribis:
>
>> Currently, (guix profiles) has code to build 'info-dir' for packages in
>> profile.
>> As mentioned in TODO, IIUC, we should move the code to 'texinfo'.
>
> Yes, that’s the initial idea. However, it’s not clear that attaching
> “user environment hooks” to packages is the right thing.
>
> For instance, you can install Info files, and if you only ever use the
> Info reader of Emacs, you never install Texinfo itself; yet, the ‘dir’
> file must be generated.
>
>> Other usecases include:
>> * hicolor-icon-theme: use gtk-update-icon-cache to get 'icon-theme.cache'.
>> * shared-mime-info: use update-mime-database to get 'mime.cache'.
>> * desktop-file-utils: use update-desktop-database to get 'mimeinfo.cache'.
>> ? glib: use glib-compile-schemas to get 'gschema.compiled'.
>
> Same problem here: users may never explicitly install GLib, yet these
> operations should always be performed.
>
> So I’m tempted to think we could just augment ‘profile-derivation’ to
> invoke other hooks similar to ‘info-dir-file’ in (guix profile). We
> could specify a list of “profile hooks” like:
>
> `(("share/info" . ,info-dir-file)
> ("share/foo/mime.cache" . ,mime-cache-file))
>
> WDYT?
OK, I'll try to do this way :)
>
>> For schemas, it's always safe for packages in system profile,
>> but may broken for user profile:
>> user had install package A
>> user update the guix disto, A -> A' has incompatible schema change
>> user now install package B' which depend on schema of A'
>> B' will crash if we have schemas from A and B'.
>>
>> If we make A a propagated-inputs of B, dose A will be update to A' when
>> install B'?
>
> Yes, when installing a package with propagated inputs, said inputs are
> installed as well, possibly overriding others. However, if you look at
> collision handling in (guix build union) is minimalist, so anything can
> happen.
>
> Thanks,
> Ludo’.
