Re: Optional runtime dependencies in Guix

[Gammel Holte]

Apologies for the really late reply. Sadly I was ill for the best part of December.

So I wouldn’t claim this is a solved problem, because it really gets
fixed when we discover a problematic case, and we certainly overlook
some of them.  Yet, that’s something I pay attention to, and I think we
must clearly look to address more of such issues.

WDYT?

I am super excited about Guix and the system seems to be progressing very quickly. Loads of commits everyday. However, the more I dig into Guix, the more i see this as an urgent issue.

For example, consider samtools, a package I use daily and that was recently committed to Guix:

http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/bioinformatics.scm#n139

It forces me to install python. In contrast, consider Arch AUR's package:

https://aur.archlinux.org/packages/samtools/

Python is listed an optional dependency. In my opinion, it is highly undesirable that Guix doesn't have a mechanism to decouple packages from optional dependencies. This scenario seems to be arising mostly in case of interpreters that may be called by the program to execute some optional stuff.

An extreme example of this is weechat:

http://lists.gnu.org/archive/html/guix-devel/2014-09/msg00229.html

Compare with:

https://www.archlinux.org/packages/extra/i686/weechat/

Guix version forces the user to install all interpreters for running user-defined scripts to extend Weechat. These are quite many: lua, perl, python, ruby, tcl (and guile).

I understand Guix/Nix philosophy and I adhere to it. But at some point we need to draw the line between a dependency and dynamic linking. Otherwise, installing a package may lead to many undesired dependencies getting installed. This has many implications, including security ones.

Best wishes,
A.

On Sun, Nov 23, 2014 at 8:47 PM, Ludovic Courtès <address@hidden> wrote:

Hello,

Gammel Holte <address@hidden> skribis:

> Nix doesn't have a good decoupling between packages and their optional
> runtime dependencies. You can disable them, but this would lead to a
> different package hash, and thus a different build (negating the use of
> prebuilt binaries).
>
> Therefore, the culture seems to have all default package builds with all
> optional runtime dependencies on. This leads to situations such as
> installing mutt, and getting python as a dependency (via mutt -> gpgme ->
> glib -> python), which is quite ugly.

That’s indeed undesirable.

As I just wrote to Taylan Ulrich, this is currently handled on a
case-by-case basis using multiple outputs (which I think Nixpkgs doesn’t
use a lot yet.)

For instance, GLib has a separate “bin” output for this very reason (see
<http://bugs.gnu.org/17853>.)  Git, as I wrote, has separate outputs for
git-svn and Tcl stuff.  Same for WordNet.  There are also separate
outputs for debugging symbols.

So I wouldn’t claim this is a solved problem, because it really gets
fixed when we discover a problematic case, and we certainly overlook
some of them.  Yet, that’s something I pay attention to, and I think we
must clearly look to address more of such issues.

WDYT?

Thanks,
Ludo’.