all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: 宋文武 <iyzsong@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: TODO: user-environment-hook
Date: Fri, 02 Jan 2015 22:38:16 +0100	[thread overview]
Message-ID: <87a920eud3.fsf@gnu.org> (raw)
In-Reply-To: <87387tzt9r.fsf@gmail.com> ("宋文武"'s message of "Fri, 02 Jan 2015 12:44:00 +0800")

宋文武 <iyzsong@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?

> 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’.

  reply	other threads:[~2015-01-02 21:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-02  4:44 TODO: user-environment-hook 宋文武
2015-01-02 21:38 ` Ludovic Courtès [this message]
2015-01-03  6:45   ` 宋文武

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a920eud3.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=iyzsong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.