Re: Optional runtime dependencies in Guix

[Gammel Holte <gammel.holte@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3312 bytes --]

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 <ludo@gnu.org> wrote:

> Hello,
>
> Gammel Holte <gammel.holte@gmail.com> 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’.
>

[-- Attachment #2: Type: text/html, Size: 4614 bytes --]